Issue: Volume output too high producing "clipping-like" noise


#1

Hi,

So far, I really enjoyed playing with my zynthian box.
However, when using the default settings, the volume output is way too high and produces clipping noise.
Basically, by using any engines and setting the instrument volume to 127, whenever I hit the keys a bit harder, the sound is clipping, even if it does not physically clip in the mixing board.

To overcome the issue, I need to lower either the instrument level or the ALSA level significantly (at least half the max value)…
I find it strange that it behaves that way, so have you guys faced such issue ?
If so, are you using custom settings to solve it ?

Btw: I am using Hifiberry dac+ with either RCA or jack as output.

Many thanks,

Pierre


#2

The default level is 96 and whilst Zynthian renders up the results of all this audio magic to the output device to chuck at the world, it’s not actually a zynth concern what it puts out. It just trusts the jack connection provided by the engine and the zynthian environment.
So it helps to know specifically which snapshot sample and engine we are talking about. A PureData component has very different issues from a fluidsynth rendition for example.

Also one can’t entirely trust a particular engine to play nicely. I spend a lot of time on the Fluidsynth harp snapshot and I’m pretty sure one of the G’s has crappy overdriven noise recorded on it. It’s one of those things that one could loose a day to pinning down and then how does one realistically pass the info back up the pipe.

The big advantage with the zynthian volume component of each engine is that it talks into the engine rather than being an audio mix component after the engines output so that control will allow you to ask the engine to reduce it’s output to a more palatable level and that’s what is actually stored in a snapshot. So once you get the level right you can easily access it repeatedly.

If you could upload an example ( yes I know the audio record get xruns it’s really a nice to have at the moment… :smiley: ) then we can set the issue in context. Obviously as a community we are really keen to make sure that when we say it works we do have a fairly good idea of what we mean by ‘works’ . . .


#3

Not if you are using an external USB pen-drive :wink:


#4

Thanks for the reply !

Well, this happens for most engines and most instruments in fluidsynth, linuxsampler and ZynAddSubFX…
Here is an audio record I just made with the FluidR3 GM/Yamaha Grand Piano.
Everything is set to its default, except the instrument volume which is set at 127.
You could clearly hear the noise. The noise also appears at default level (96) but is less audible.


#5

I’ll try with a less give away pen drive …


#6

Here is another take, with a pretty decent USB drive, and you can still hear the same clipping, noise…


#7

It seem that is a little interruption of sound…not a clipping


#8

Looks like we need a base line here. Does it always seem to occur in the same place and can we relate it to anything like an xrun. We need to establish around one specific snapshot and perhaps a simple sine wav sample might be a good place to start. I wonder how many different way there are of producing a 0dB 1KHz tone…?


#9

(Not met Goldwave)
Are those renders of admin function audio recording or audio output recordings from the DAC?


#10

Is the plot of a part of the the second file posted by @pierrecnalb


#11

I am not sure I understood properly the suggestion… Are you suggesting to create a simple soundfont for fluidsynth that contains a simple sine wave and see if the issue is reproducible ?
I can definitely try this.


#12

Well we need is a repeatable instance of the fault. I suggest a sine wave simply because it is something we could produce on most engines IT’s not really a requirement for this fault but it would be the most sensible starting point for comparative testing. The concerns here are is there a genuine repeatable artifact occurring on one or several engines?
Is it performance related?
Is it always at precisely the same time or is it a random event?
Can the fault be duplicated on other zynthians?
What sort of test rig (midi file played -> engine -> D/A or midi file played -> engine -> audio record function) produces the fault?

As I’ve said I’ve had issues with the admin record function and have experienced silent periods as described by videobelu.
The main concern is are these repeatable on D/A output?
Once we have confirmed or disproved the repeatability on different machines of a specific fault then we can investigate it. I obviously am not speaking on behalf of the zynthian project here but I hope I am collating issues that obviously affect us as a community.
Any comments would be of great benefit in pinning the issue down.


#13

I’m a little bit confused with the thread title … are we talking about audio output or about internal audio recording?

  • Regarding the “internal audio recording”, i’m just tested and yes, it produces these “clips/silences” when you use an USB pen-drive, so i’ve to study the problem …

  • Regarding the audio output, it’s OK for me, but if most of people think so, i could reduce the default level in all engines …

Regards,


#14

I think it would be useful to reduce the output to ~80% to get some headroom for more silents sounds (IMHO!).

Do we have dwc_otg.speed=1 in /boot/config.txt?

(This is only a workaround, and restricts the USB controller to USB 1.1 mode and therefore limits all USB devices (including the onboard network adaptor) to 12Mbps) [Source: https://github.com/raspberrypi/linux/issues/2215]

Regards, Holger


#15

The other advantage of using a sine wave ( or perhaps a ramp) is that we can specify correct line level at the output of jack. Presumably we should be rendering audio at some ‘standard’ audio specification and as we are going out via a D/|A we want to have a reference 1Khz tone produce 0.775mV into 600ohms.
Or to me 4 on a PPM

If we are seeing overdriving then we want to be sure that we make the best effort to make sure the engines all sing similarly. We want to produce an output level based on a spec that can be turned away from that standard if the users feels that is required or desired.

Othewise how about -10dB pad as a selection option in the Audio Config?


#16

Very good idea @wyleu! Where is my scope???
AMvEtLN2HRoVIXrBailADjq2pAmdN3p-gEXO6ZJjWPw

Also a very good idea!

Regards, Holger


#17

OHM OHM ON THE RANGE!!


#18

The real problem is about audio output. The audio recording was just to show the issue, but it first occurs on the D/A output.

So, it looks like both, but originally that was midi -> engine -> D/A

I currently do not have my zynthian box, but I’ll try to make the simple sine wave test when I can.

Thanks for all the reply ! Really appreciated !


#19

We need evidence of actual D/A output mutes before running up the alarms.

If we have mutes in the D/A output then it would be expected that reducing the output level would not reduce the amount of error as has been described.
I will try to set up something as well to see if I can detect anything with my various output configs. I will try to see what I can get from a decent microphone with my hifiberry speakers and my own ‘standard’ zynthian kit.
I don’t anything on the GM Yamaha Piano which I use a lot but Audacity might reveal something else.