E-MU 0404 and Linux (also issues with capture at 96 kHz)
Hi all,
I have recently bought a nice E-MU 0404 USB, with the idea of using it under Linux for measurements.
My first question is about what appears in alsamixer: there are two sliders labeled "PCM front" and "PCM rear". They don't seem to affect the audio output and I cannot figure out what do they control (this card should not have any digital mixer or gain control). Has anybody a clue?
The second issue I have with REW. The card works consistently at 48 and 192 kHz, noise floor is OK and digital input are - as expected - mute (REWs reads something like -487.7 dbFS when they are off/undriven). Channels should be:
- 1, 2 <-> analog R, L
- 3, 4 <-> digital R, L
Now the problems arise at intermediate rates. At 96 kHz all channels get screwed up:
- 1 <-> a sinc function (!) repeating with a 2 kHz frequency and peaked at -120 dbFS;
- 2, 3 <-> analog R, L but with a -55 dBFS noise floor and apparently very high gain;
- 4 <-> some signal on the same scale of (1) but without a recognizable shape (although it looks deterministic).
It's clear that somehow the card gets a few things screwed up when driven at 96 kHz in full duplex. This thread on LinuxMusicians reports something that sound familiar to my situation, e.g. anomalous high gain on the analog channels. They also suggest that forcing the number of channel to two for the capture subdevice via QJackCtl seems to fix the issue, however I am not sure how to do it in ALSA.
I am using Fedora 29 running kernel 5.0.19-200, so a pretty up-to-date system.
Kindly asking for help:
- anybody with an E-MU 0404 USB can reproduce?
- if not reproducible, what distribution/kernel are you running on?
- how to force the capture subdevice into 2ch mode?
- what could be ultimately the cause of this anomaly? (and for academic purposes, what's a sinc function doing there?)
I could live with the situation (after all 192 kHz work fine) but since this is a nice piece of hardware and Linux the only hope for long term support, maybe it's worth trying to sort this out.
Hi all,
I have recently bought a nice E-MU 0404 USB, with the idea of using it under Linux for measurements.
My first question is about what appears in alsamixer: there are two sliders labeled "PCM front" and "PCM rear". They don't seem to affect the audio output and I cannot figure out what do they control (this card should not have any digital mixer or gain control). Has anybody a clue?
The second issue I have with REW. The card works consistently at 48 and 192 kHz, noise floor is OK and digital input are - as expected - mute (REWs reads something like -487.7 dbFS when they are off/undriven). Channels should be:
- 1, 2 <-> analog R, L
- 3, 4 <-> digital R, L
Now the problems arise at intermediate rates. At 96 kHz all channels get screwed up:
- 1 <-> a sinc function (!) repeating with a 2 kHz frequency and peaked at -120 dbFS;
- 2, 3 <-> analog R, L but with a -55 dBFS noise floor and apparently very high gain;
- 4 <-> some signal on the same scale of (1) but without a recognizable shape (although it looks deterministic).
It's clear that somehow the card gets a few things screwed up when driven at 96 kHz in full duplex. This thread on LinuxMusicians reports something that sound familiar to my situation, e.g. anomalous high gain on the analog channels. They also suggest that forcing the number of channel to two for the capture subdevice via QJackCtl seems to fix the issue, however I am not sure how to do it in ALSA.
I am using Fedora 29 running kernel 5.0.19-200, so a pretty up-to-date system.
Kindly asking for help:
- anybody with an E-MU 0404 USB can reproduce?
- if not reproducible, what distribution/kernel are you running on?
- how to force the capture subdevice into 2ch mode?
- what could be ultimately the cause of this anomaly? (and for academic purposes, what's a sinc function doing there?)
I could live with the situation (after all 192 kHz work fine) but since this is a nice piece of hardware and Linux the only hope for long term support, maybe it's worth trying to sort this out.
Last edited:
Thank you. I posted on the REW forum before, but decided to try here as it's more likely I will find experts for the Linux part.
John actually suggested it may be some sample format / word length issues that causes input data to be improperly parsed. That would explain why (1) ch1 and ch4 seem pure artifacts (2) analog signals seems raised in level.
I checked that the same anomaly appears also with Ardour, so I just changed the topic title in "issues with capture", since it's not a REW-specific problem (but REW it's the quickest way to see it).
Likely a driver bug, then :/
Great, your feedback will be greatly appreciated.
Is it possible that this has to do with the kernel loading the default USB sound driver instead of the emu10k1 that should support the FPGA on board? Unless this is misdocumented and emu10k1 has to do only with PCI acquisition.
Last edited:
EMU 0404 and 0202 work fine under linux, thought I have some funny "Glitchs" at 48KHz, after @phofman got WDM to work for me so I could do 192KHz.
Also with jackd/WinAsio it works but only up to 96KHz ans that is without the "Glitchs".
@phofman any idea why ? I use it with Arta and have tried REW and it work too.
Also with jackd/WinAsio it works but only up to 96KHz ans that is without the "Glitchs".
@phofman any idea why ? I use it with Arta and have tried REW and it work too.
Guess I can add some more information about my tests with arecord:
So for some reason Java/REW get access to the board in 2ch mode at 192 kHz, but in 4ch mode at 96 kHz. Since the latter is unsupported by the driver, it does not work.
I am not aware how the negotiation of hw parameters works between Java and ALSA. If one could force the driver to provide by default 2ch access at 96 kHz, the problem would be solved. Of course it would be even nicer to have support for 4ch @ 24/96 capture in the driver.
It's still to be determined what is the purpose of the "PCM Front" and "PCM Rear" sliders in alsamixer, to me they seem 100% ineffective (probably they are used in some different hardware using the same chipset).
Looking forward from findings of @phofman
- 2ch capture works all the way up to 24/192
- 4ch capture works only up to 24/48
- 4ch capture is permitted at 24/96 or 24/192 but apparently not supported: arecord produces a sound file with wrong channel mapping, wrong scale (on analog inputs) and artifacts (instead of digital inputs).
So for some reason Java/REW get access to the board in 2ch mode at 192 kHz, but in 4ch mode at 96 kHz. Since the latter is unsupported by the driver, it does not work.
I am not aware how the negotiation of hw parameters works between Java and ALSA. If one could force the driver to provide by default 2ch access at 96 kHz, the problem would be solved. Of course it would be even nicer to have support for 4ch @ 24/96 capture in the driver.
It's still to be determined what is the purpose of the "PCM Front" and "PCM Rear" sliders in alsamixer, to me they seem 100% ineffective (probably they are used in some different hardware using the same chipset).
Looking forward from findings of @phofman
Have a look at this bash shell script
It'll give you a detailed list of devices and their capabilities.
It would also be beneficial to create a .asoundrc in your home directory, this will define defaults for the various inputs / outputs.
I also find Debian to be the best Linux distro for audio, it always just works for me.
There are various ways to 'talk' to the sound card in Linux.
Finally,
will also give a long list of addressable devices. (note the capital L)
It'll give you a detailed list of devices and their capabilities.
It would also be beneficial to create a .asoundrc in your home directory, this will define defaults for the various inputs / outputs.
I also find Debian to be the best Linux distro for audio, it always just works for me.
There are various ways to 'talk' to the sound card in Linux.
Finally,
Code:
aplay -LThe card has arrived, I could not help but do my hobby instead of work. I think I will have to fire myself
The device seems to behave OK. It offers quite a few altsettings (param combinations):
As listed - for 2 channels the samplerates go from 44100 to 192000. For 4 channels from 44100 to 96000 only.
I will test spectrum quality at home.
The device seems to behave OK. It offers quite a few altsettings (param combinations):
Code:
cat /proc/asound/card2/stream0
E-MU Systems, Inc. E-MU 0404 | USB at usb-0000:00:1a.7-4, high speed : USB Audio
Playback:
Status: Stop
Interface 1
Altset 1
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 44100
Data packet interval: 1000 us
Interface 1
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 44100
Data packet interval: 500 us
Interface 1
Altset 3
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 48000
Data packet interval: 1000 us
Interface 1
Altset 4
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 48000
Data packet interval: 500 us
Interface 1
Altset 5
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 88200
Data packet interval: 1000 us
Interface 1
Altset 6
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 88200
Data packet interval: 500 us
Interface 1
Altset 7
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 96000
Data packet interval: 1000 us
Interface 1
Altset 8
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 96000
Data packet interval: 500 us
Interface 1
Altset 9
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 176400
Data packet interval: 500 us
Interface 1
Altset 10
Format: S24_3LE
Channels: 2
Endpoint: 1 OUT (ASYNC)
Rates: 192000
Data packet interval: 500 us
Interface 1
Altset 11
Format: S24_3LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 44100
Data packet interval: 1000 us
Interface 1
Altset 12
Format: S24_3LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 44100
Data packet interval: 500 us
Interface 1
Altset 13
Format: S24_3LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 48000
Data packet interval: 1000 us
Interface 1
Altset 14
Format: S24_3LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 48000
Data packet interval: 500 us
Interface 1
Altset 15
Format: S24_3LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 88200
Data packet interval: 500 us
Interface 1
Altset 16
Format: S24_3LE
Channels: 4
Endpoint: 1 OUT (ASYNC)
Rates: 96000
Data packet interval: 500 us
Capture:
Status: Stop
Interface 2
Altset 1
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 44100
Data packet interval: 1000 us
Interface 2
Altset 2
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 44100
Data packet interval: 500 us
Interface 2
Altset 3
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 48000
Data packet interval: 1000 us
Interface 2
Altset 4
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 48000
Data packet interval: 500 us
Interface 2
Altset 5
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 88200
Data packet interval: 1000 us
Interface 2
Altset 6
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 88200
Data packet interval: 500 us
Interface 2
Altset 7
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 96000
Data packet interval: 1000 us
Interface 2
Altset 8
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 96000
Data packet interval: 500 us
Interface 2
Altset 9
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 176400
Data packet interval: 500 us
Interface 2
Altset 10
Format: S24_3LE
Channels: 2
Endpoint: 2 IN (ASYNC)
Rates: 192000
Data packet interval: 500 us
Interface 2
Altset 11
Format: S24_3LE
Channels: 4
Endpoint: 2 IN (ASYNC)
Rates: 44100
Data packet interval: 1000 us
Interface 2
Altset 12
Format: S24_3LE
Channels: 4
Endpoint: 2 IN (ASYNC)
Rates: 44100
Data packet interval: 500 us
Interface 2
Altset 13
Format: S24_3LE
Channels: 4
Endpoint: 2 IN (ASYNC)
Rates: 48000
Data packet interval: 1000 us
Interface 2
Altset 14
Format: S24_3LE
Channels: 4
Endpoint: 2 IN (ASYNC)
Rates: 48000
Data packet interval: 500 us
Interface 2
Altset 15
Format: S24_3LE
Channels: 4
Endpoint: 2 IN (ASYNC)
Rates: 88200
Data packet interval: 500 us
Interface 2
Altset 16
Format: S24_3LE
Channels: 4
Endpoint: 2 IN (ASYNC)
Rates: 96000
Data packet interval: 500 usAs listed - for 2 channels the samplerates go from 44100 to 192000. For 4 channels from 44100 to 96000 only.
I will test spectrum quality at home.
You can do it very simple:
Code:
aplay --dump-hw-params -D hw:2,0 /dev/zero
Playing raw data '/dev/zero' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:2,0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S24_3LE
SUBFORMAT: STD
SAMPLE_BITS: 24
FRAME_BITS: [48 96]
CHANNELS: [2 4]
RATE: [44100 192000]
PERIOD_TIME: [500 1981429)
PERIOD_SIZE: [23 87381]
PERIOD_BYTES: [138 524288]
PERIODS: [2 1024]
BUFFER_TIME: (239 3962858)
BUFFER_SIZE: [46 174762]
BUFFER_BYTES: [276 1048576]
TICK_TIME: ALL
--------------------
aplay: set_params:1233: Sample format non available
Available formats:
- S24_3LE
arecord --dump-hw-params -D hw:2,0 /dev/null
Recording WAVE '/dev/null' : Unsigned 8 bit, Rate 8000 Hz, Mono
HW Params of device "hw:2,0":
--------------------
ACCESS: MMAP_INTERLEAVED RW_INTERLEAVED
FORMAT: S24_3LE
SUBFORMAT: STD
SAMPLE_BITS: 24
FRAME_BITS: [48 96]
CHANNELS: [2 4]
RATE: [44100 192000]
PERIOD_TIME: [500 1981429)
PERIOD_SIZE: [23 87381]
PERIOD_BYTES: [138 524288]
PERIODS: [2 1024]
BUFFER_TIME: (239 3962858)
BUFFER_SIZE: [46 174762]
BUFFER_BYTES: [276 1048576]
TICK_TIME: ALL
--------------------
arecord: set_params:1233: Sample format non available
Available formats:
- S24_3LEI do not see any driver problem with the soundcard. All freqs seem to work OK for both analog channels (1st, 2nd). The 3rd+4th channels are for SPDIF output/input.
But left channel has some USB/processing noise, much higher than the right one. I have joint-compensated all harmonics of 1211Hz fundamental (chosen not to be multiple of 1kHz) with my tool Digital Distortion Compensation for Measurement Setup - the spectra without the harmonics show the difference between left and right channels clearly. The tool screen lists all the removed harmonics.
The results are not bad but comparable to my PCI Infrasonic Quartet soundcard. I did not expect the USB artefacts. Honestly, I am a bit disappointed.
But left channel has some USB/processing noise, much higher than the right one. I have joint-compensated all harmonics of 1211Hz fundamental (chosen not to be multiple of 1kHz) with my tool Digital Distortion Compensation for Measurement Setup - the spectra without the harmonics show the difference between left and right channels clearly. The tool screen lists all the removed harmonics.
The results are not bad but comparable to my PCI Infrasonic Quartet soundcard. I did not expect the USB artefacts. Honestly, I am a bit disappointed.
Attachments
Last edited:
This is a known issue, due to some sub-optimal routing of some lines. I agree it's disappointing, it could have been easy to avoid it.
On the other hand I cannot think of another USB interface providing similar performance without going up to several hundreds of euros.
The two other channels are for SPDIF (in/out), playback/recording requires looping back with a digital cable (coax/toslink). Did you have it connected? It is possible the recording does not work correctly when no SPDIF signal is present at the digital input, corrupting the whole frame (analog + digital channels)
I will test it.
Unfortunately all the USB soundcards I have seen have the 1kHz artefact. It looks like avoiding it requires an extra effort (QA401 seems OK). Most measurements are at 1kHz which hides the artefact.
But measuring with the E-MU right channel should be OK when using non-1kHz signal. Most precision measurements require only one capture channel anyway.
This does not happen at 4 x 48 kHz where the digital channels simply read zero. Also, 4 x 96 kHz in Windows works fine.
I have not tried at 4 x 96 kHz with a digital loopback in Linux (I won't be able to put my hands again on it for another ~1.5 week).
My specific problem under Linux is that Java/REW access the board at 4ch x 96 kHz, so even if you analyse only one channel the capture is screwed up. As a workaround, I should try a way to force the access in 2ch mode (or veto the 4 x 96).
Thanks for taking interest in this!
I will try it this week.
Try this in your .asoundrc and use the newly configured PCM device emu2ch in java. It should force 2-channel mode, thus making the USB-audio driver use the 2-channel usb altsettings, instead of the 4ch ones.
Code:
pcm.emu2ch {
type hw
card "USB"
device 0
format S24_3LE
channels 2
}It is my interest too
I need a decent usb device for my project.- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.