hf noise in output at 176 and 196kHz about emu-driver HOT 35 OPEN

is it easy to enable the 0.5ms USB buffer for 44.2k sample rates? then we can test if that is the cause of the noise. Is the existence of the different usb modes speculative or is it referenced in the driver code?

from emu-driver.

I checked this. Just recording silence with the loopback from output to input 2.

I also get some noise at -42dB.

Amplified it looks like this here

from emu-driver.

There is a HF and a LF component in there. (notice, amplified already with 40dB)

from emu-driver.

My first guess is that we are seeing just environment noise here. Maybe they just decouple the mains output completely? I will try to play back something soft and see if the noise is still there

from emu-driver.

is it easy to enable the 0.5ms USB buffer for 44.2k sample rates? then we can test if that is the cause of the noise. Is the existence of the different usb modes speculative or is it referenced in the driver code?

Not sure how difficult that is. I expect it will be not too hard.A few hours if no new bugs appear. Plus a few hours testing.

But I don't believe this has anything to do with the USB rate. I think the DAC and filtering changes (nyquist limit ggoes up to 92kHz now so we get all the noise that was previously filtered out) and that's why we are getting more noise at this point.

There are mods for the EMU to lower this noise. Yes I saw somewhere that the left channel is close to a USB line if I remember it right.

Also part of this noise might be coming from the power supply. I will test if that makes a difference.

from emu-driver.

Put the EMU on a battery. Makes no difference, still same noise at 40kHz.

The noise is LF, the noise at -40dB is 50Hz mains noise, Might be that my cables are rotten, too long or whatever.

There is only hf noise at -85dB (-45dB after amplification with 40dB, see picture).Again, maybe the cables.

If I unplug the cables entirely, I have hardly any noise. This is after 50dB amlification. Without amplification the plot would remain completely empty (everything below -90dB)

from emu-driver.

Tom, here the HF component is much lower. Can you re-check? Could it be the cables picking up something? Wifi noise or computer/screen noise for instance?

from emu-driver.

my noise floor at the lower 4 sample rates is -85dB, I'm not getting the hum or anything.

with a loopback cable plugged in it depends on the input gain of course, but it is still ok.

looks like you are not getting the same noise as me at 192 and 176k rates.

-40dB digital rubbish noise is not considered at all acceptable. But mine does look like maybe it could be switching power supply noise. There must be DC-DC converter in there....

It would seem surprising if this is just due to the antialiasing filter being at a different frequency.

However it seems that you are not getting the noise I do, so maybe there is a hardware difference between the units?

from emu-driver.

I checked again. the noise is still there at 192k.

actually is is -40dB with the input gain all the way down, if I increase the gain I can record it at any level up to clipping.

so it is a loud noise.

the cable is only 50cm long, and has worked fine for everything else.

it is far enough from screens etc that I don't think that is the problem

from emu-driver.

I tried turning off everything else nearby, wifi, phone, led lights etc, no change

from emu-driver.

However it seems that you are not getting the noise I do, so maybe there is a hardware difference between the units?

Yes the hardware is different. The DAC is even different.

Might be some design flaw on the board.

50cm is long enough to pick up a lot of noise.... Some mobile phone signals cut through almost everything...

What do you see if you don't connect any cable?

from emu-driver.

some DACs get unstable at very high rates, many people avoid the very high rates because of this, also because of intermodulation distortion from inaudibly high sounds being created in speakers etc... but this seems much more extreme than any of that...

Ideally, filter should not be the same shape filter as 96k but up an octave, it should be a gentler lower order filter starting at the same frequency.

from emu-driver.

no noise with no cable,

no noise with cable on input but not plugged into output.

from emu-driver.

actually with the cable plugged into the input but not the output, so it is acting just as an unterminated High Z antenna, then I do have noise, but it is a completely different lower level noise such as you would expect in this case.

from emu-driver.

ok so it seems the hf noise is really coming from your DAC then. Do you think this is a design flaw or jjust a problem with your unit?

from emu-driver.

Time's up for now, thanks for all the help so far!

from emu-driver.

ok so it seems the hf noise is really coming from your DAC then. Do you think this is a design flaw or jjust a problem with your unit?

really hard to tell. If I can find time to test with other computers that may shed some light on it.

It seems more like a bug (firmware) than a design flaw, and not much like a fault, since it is fine at lower rates. Maybe if the filter for the high rates was badly broken/not working at all? even then I would expect less noise than this.

there are different settings fo each type of hardware in the plist, how different are the settings in the driver for each unit? could there be a setting that is correct for the 0404 and wrong for the tracker?

from emu-driver.

There is nothing special in the plists. It just indicates number of channels, names of channels, manufacturer etc.

The only things I don't know there is TransportTypeOverride, bConfigurationValue and bInterfaceNumber. These are all the same for all devices except that tracker pre ddoes not have a TransportTypeOverride.

from emu-driver.

could there be some sort of clock issue?

I don't understand all the buffers and so on, and how the driver works, but I think I read somewhere that the whole thing is loosely synced to the ADC clock is that right?

some pro audio interfaces allow the user to select the clock source for the whole system, ie DAC internal clock, computer internal clock, external clock on spdif or on word clock and so on.

I wondered if the 192k nose could be a clock sync failure of some sort? clocking 4x sample rates accurately is notoriously problematic, so I wondered if it could be pushing something over the edge.

the 0404 has a spdif out and in so I wonder if it handles clocking differently/better

from emu-driver.

I don't understand all the buffers and so on, and how the driver works, but I think I read somewhere that the whole thing is loosely synced to the ADC clock is that right?

No, not "loosely synced". This clock sync is critical for proper operation and is the most difficult part of the driver. It is synced very tight both in speed and in phase.

some pro audio interfaces allow the user to select the clock source for the whole system, ie DAC internal clock, computer internal clock, external clock on spdif or on word clock and so on.

EMU allows sync on the S/PDIF. Core Audio handles the rest of the sync issues to get the whole system in sync. These are different levels of sync however.

I wondered if the 192k nose could be a clock sync failure of some sort? clocking 4x sample rates accurately is notoriously problematic, so I wondered if it could be pushing something over the edge.

I expect a different kind of noise if the sync is off. Normally if the sync is off there will be buffer over/underflows and you will get very noticeable clicks.

the 0404 has a spdif out and in so I wonder if it handles clocking differently/better

I don't expect so. S/PDIF signals must be generated in the EMU and it has to use its clock for that. So you are then back to the clock accuracy of the EMU.

from emu-driver.

No, not "loosely synced". This clock sync is critical for proper operation and is the most difficult part of the driver. It is synced very tight both in speed and in phase.

OK, I used the word loosely because If it was really tight ie perfectly synced every sample right through the data chain then why would we need all these buffers at different stages?

So I think I used loosely differently from what you understood it to mean. I take from your comment that the sync is exact, but not realtime.

My understanding is that the data is transmitted in chunks/frames/packets and then the per sample timing is reconstructed at the other end.

I was wondering if the noise could be a clock inaccuracy that creates a error at every sample, but maybe this is impossible because the data is transmitted in packets?

from emu-driver.

They need the buffers because there are different threads on different CPUs involved. And because you don't want to handle every byte that comes in separately, the overhead costs for handling that single byte would become way too large. So you wait till there's a good amount of work to be displaced before starting working on it. Even in perfect sync this would be necessary.

My understanding is that the data is transmitted in chunks/frames/packets and then the per sample timing is reconstructed at the other end.

yes roughly.

I was wondering if the noise could be a clock inaccuracy that creates a error at every sample, but maybe this is impossible because the data is transmitted in packets?

The EMU determines the sample clock (but it in turn may be slaved to SPDIF). So whatever comes in, the clock is stable and is clocked in a stable way to the DAC

from emu-driver.

So you wait till there's a good amount of work to be displaced before starting working on it. Even in perfect sync this would be necessary.

Is there also a jitter/desynchronisation between the USB hardware which has it's own internal timing, and the digital audio clock, so a buffer is necessary to even it out? If the USB bus could be made to run with it's packets in perfect sync with the audio clock packets then we would need one fewer buffer?

from emu-driver.

Yes there also buffers are needed.

If the USB bus could be made to run with it's packets in perfect sync with the audio clock packets then we would need one fewer buffer?

The USB bus always has ITS OWN clock determined by the host = computer.

Some audio devices run based on that clock. That may solve some sync issues yes.

But IMHO for audio this is not desirable as this clock is not designed with the required stability of audio in mind. Instability in the audio clock will result in noise in the conversion. Therefore I think the EMU made the right choice regarding this.

We still would need the buffer I think for reasons I mentioned.

from emu-driver.

Could this be related to #46?

from emu-driver.

hmm, we never solved this, and I don't use 4x sample rates so I forgot about it until I just tested latency at 4x.

I have not experienced the issue with the headphones referenced at #46, also I just tested and plugging the headphones in makes no difference to the HF noise at 4x rates.

from emu-driver.

What do you mean with 4x rates, the 176k and 192k?

I will move your comment on #46 to #46

from emu-driver.

My hunch is that this noise is coming from the DAC.

There is an analog low pass filter behind the DAC.

For the total picture, THD+N is also defined between 0 and 20kHz only (p.25 "measurement bandwidth is 10 Hz to 20 kHz"). The stopband starts only at 0.635Fs = 122kHz (@192k). The specs of the analog filter area siilarly specify 0.01dB error UP TO 20 KHZ only.

I can't seem to find what happens between 20kHz and 96kHz (the max frequency).

from emu-driver.

For the AK4396, the specs use different bandwidths - they measure up to 40kHz for the 96kHz sample rate and up to 80kHz for the 192k rate.

Actually, they SPECIFY -51dB THD+N at 80kHz for the 192kHz rate, which seems to match my measurement above. But I'm not sure if I get this correctly since they also specify -54dB at 40kHz while I would think it's actually -110dB if I look at my measurement.

from emu-driver.

What do you mean with 4x rates, the 176k and 192k?

yes

I will move your comment on #46 to #46

it was really more a comment on 43 because I was commenting that 43 and 46 are unrelated.

from emu-driver.

I can't seem to find what happens between 20kHz and 96kHz (the max frequency).

are these oversampling DACs? almost all modern DACs are oversampling and so the analog filter is at a much higher frequency than you would expect, or a much gentler slope, since the converter is actually working at many times the real sample rate.

I am pretty sure that the noise is not expected behavior, even if it is within some spec.

from emu-driver.

Yes they are oversampling. Yes, it is possible to move the HF noise further up so that it is no issue for the analogue part. But they can also do other things with the oversampling I think like increasing the effective number of bits.

Maybe they used the oversampling not to push the noise out far enough.

from emu-driver.

Today I found also HF noise when sampling at 192k with 64samples buffer size. But it looks different than Tom's. I have this when doing a loopback of 440Hz sinus 96kHz wave from reaper.

Here below is a 50dB amplified after notch filtering out the 440Hz sinus.
But I'm not sure, this could be also a processing artefact eg realtime upsampling or the export process from reaper.

Notice, thelow amplitude zigzag is 50 Hz hum

from emu-driver.

Here's the noise over a 10 minute period (192k, 128samples buffer) amplified 40dB . THere seems some pattern in there, blocks with and without the noise. The noise is there both with 64samples and with 128 samples buffer size in reaper.

from emu-driver.

It could also be some cheap upsampling process as the original 440Hz wave is only 92kHz

from emu-driver.