Here is a link to a full thread on the rework. E-MU 0404 usb 2.0 and some "artifacts peaks" on left channel It should help.
Thanks a lot.
The simple fix seems to work (I really wonder how they could route balanced signals that way). Both channels have basically same performance now (screenshots of joint-sides compensation at 1211Hz). It would have been better without the 1kHz USB artefact 🙂
The simple fix seems to work (I really wonder how they could route balanced signals that way). Both channels have basically same performance now (screenshots of joint-sides compensation at 1211Hz). It would have been better without the 1kHz USB artefact 🙂
Attachments
The 4ch capture at > 48kHz is corrupted indeed. It looks like the CA0188 processor in E-MU sends samples in some incorrect byte order/position. Drivers for the old PCI E-MU cards had to take care of the FPGA firmware (sending programming commands), but the USB soundcard driver does not have to handle the firmware anymore (fortunately). IMO the windows E-MU driver fixes the stream received over USB.
I sent a question to the alsa-devel mailing list, hopefully it will reach some of the older E-MU PCI driver authors who could perhaps help with more info.
[alsa-devel] E-MU 0404 USB - 4ch capture at > 48kHz -> corrupted data
Fortunately I do not need the SPDIF input for my purpose but it would be nice to have the driver fixed.
I sent a question to the alsa-devel mailing list, hopefully it will reach some of the older E-MU PCI driver authors who could perhaps help with more info.
[alsa-devel] E-MU 0404 USB - 4ch capture at > 48kHz -> corrupted data
Fortunately I do not need the SPDIF input for my purpose but it would be nice to have the driver fixed.
I think the REW <-> E-MU 0404 USB issue is this:
E-MU
---------
* E-MU alsa driver does not work correctly with 4ch capture at > 48kHz
* but in .asoundrc you can configure a 2ch PCM device which always uses the 2ch altsetting, thus working OK for all freqs with analog in/out
REW
-------
* REW offers sound devices it gets from java audio layer.
* It always opens the device at maximum channel count it finds
* Therefore it forces the non-working 4ch altsetting + no support for > 96kHz with E-MU
Java
-------
* Java can only enumerate audio cards (using alsa API snd_card_next), not individual PCM devices:
jdk11u/PLATFORM_API_LinuxOS_ALSA_PCMUtils.c at 737d8437886ad97c6ed21a25b9911c10b3886f61 * openjdk/jdk11u * GitHub
ubuntu - Use ALSA pcm outputs via the Java SoundSystem - Stack Overflow
E.g. portaudio enumerates over cards the same way as java does Source | Git | Assembla but then iterates over all plugin-defined PCM devices Source | Git | Assembla .
Available solutions
-------------------------
A) Fixing the USB driver. Still the 4-chans will not support 192kHz (by E-MU design)
B) Adding PCM enumeration to JDK - would be very useful but rather complicated
C) Having REW open the soundcard with configurable number of channels. I have not tried but REW authors should be able to at least test if they can do it (I saw the recent discussion about this issue on their forum).
D) Setting-up the CAPTURE chain like this: REW -> alsa looback device (creates a card, will be avaiable in java/REW) -> alsaloop utility -> emu2ch PCM device -> E-MU in 2ch mode.
Only option D makes it with configuration/setup only, all other options need coding.
I would love option B as user-defined alsa PCM devices can do magic and java software needs access to them.
E-MU
---------
* E-MU alsa driver does not work correctly with 4ch capture at > 48kHz
* but in .asoundrc you can configure a 2ch PCM device which always uses the 2ch altsetting, thus working OK for all freqs with analog in/out
Code:
pcm.emu2ch {
type hw
card "USB"
device 0
format S24_3LE
channels 2
}REW
-------
* REW offers sound devices it gets from java audio layer.
* It always opens the device at maximum channel count it finds
* Therefore it forces the non-working 4ch altsetting + no support for > 96kHz with E-MU
Java
-------
* Java can only enumerate audio cards (using alsa API snd_card_next), not individual PCM devices:
jdk11u/PLATFORM_API_LinuxOS_ALSA_PCMUtils.c at 737d8437886ad97c6ed21a25b9911c10b3886f61 * openjdk/jdk11u * GitHub
ubuntu - Use ALSA pcm outputs via the Java SoundSystem - Stack Overflow
E.g. portaudio enumerates over cards the same way as java does Source | Git | Assembla but then iterates over all plugin-defined PCM devices Source | Git | Assembla .
Available solutions
-------------------------
A) Fixing the USB driver. Still the 4-chans will not support 192kHz (by E-MU design)
B) Adding PCM enumeration to JDK - would be very useful but rather complicated
C) Having REW open the soundcard with configurable number of channels. I have not tried but REW authors should be able to at least test if they can do it (I saw the recent discussion about this issue on their forum).
D) Setting-up the CAPTURE chain like this: REW -> alsa looback device (creates a card, will be avaiable in java/REW) -> alsaloop utility -> emu2ch PCM device -> E-MU in 2ch mode.
Only option D makes it with configuration/setup only, all other options need coding.
I would love option B as user-defined alsa PCM devices can do magic and java software needs access to them.
Last edited:
I have added an option to limit access to the soundcard to stereo for the next beta build (V5.20 beta 13). Which channels are offered is something I can't influence, JavaSound will request a stereo line and will take whatever line or lines are returned.
Thanks a lot for your fast response 🙂 I will check the altsetting used when the new beta is out.
I have proposed the change at the java sound mailing list, we will see the response.
<Sound Dev> Support for linux alsa PCM devices
<Sound Dev> Support for linux alsa PCM devices
Thank you Pavel for the debug and all the actions taken, and thank you John for the workaround in the application.
It would be great to see this fixed in the driver but likely most of the original developers are not "alive" anymore in the community.
I guess we provided good help to anyone else who is still playing around with this device!
It would be great to see this fixed in the driver but likely most of the original developers are not "alive" anymore in the community.
I guess we provided good help to anyone else who is still playing around with this device!
You are welcome. I want my hardware to be supported to maximum possible. In linux the options are in our hands, unlike in closed-source OSes.
Authors of the original driver are most likely still hanging around the alsa-devel mailing list. Nevertheless I doubt it will be fixed, unless someone steps in with some documentation. Creative/E-MU guys have the know-how but so far they have not been overly helpful...
I would like java to support the PCM devices (solution B). The patch itself would not be complicated, but the process of pushing it into mainline java is not exactly friendly... OpenJDK: How to contribute .
Authors of the original driver are most likely still hanging around the alsa-devel mailing list. Nevertheless I doubt it will be fixed, unless someone steps in with some documentation. Creative/E-MU guys have the know-how but so far they have not been overly helpful...
I would like java to support the PCM devices (solution B). The patch itself would not be complicated, but the process of pushing it into mainline java is not exactly friendly... OpenJDK: How to contribute .
Last edited:
The java patch has been given a go-ahead, now it is my turn. It will take a while though, too many projects underway...
<Sound Dev> Support for linux alsa PCM devices
<Sound Dev> Support for linux alsa PCM devices
The new "stereo" option in latest beta REW works correctly, java picks the 2ch modes and selects 2ch altsettings all the way up to 192kHz.
For 96kHz the REW generator/analyzer combo is rock solid. For 192kHz there are dropouts in the stream, making the spectrum "flicker", unable to average for any useful time.
Alsa works with two blocks - period and buffer. Period is time/buffer between two soundcard interrupts. Buffer is the block of samples used by the soundcard's DMA engine. While e.g. ASIO has hard-coded 2 periods in buffer, alsa has the number of periods within buffer configurable from 2 to whatever the driver allows.
In java the buffer size is configurable, directly related to the buffer size param in REW. Indeed, 128k of samples translate to buffer_size of the alsa driver (128k = 131072):
However the period size, which tells how often java thread is asked/awoken to supply/provide data, is hardcoded at 20ms (i.e. 3840 samples at 192kHz samplerate)
jdk/PLATFORM_API_LinuxOS_ALSA_PCM.c at 6bab0f539fba8fb441697846347597b4a0ade428 * openjdk/jdk * GitHub
jdk/PLATFORM_API_LinuxOS_ALSA_PCM.c at 6bab0f539fba8fb441697846347597b4a0ade428 * openjdk/jdk * GitHub
That value works OK for simple utils like aplay/arecord (which produce no xruns down to the minimum 500us period time specified by the device), but is apparently too small for processing in java.
When I work on the patch for PCM devices, I will try to make this value also configurable via some environment variable. The latency will grow, but that is no problem for use case like this. Hopefully the java audio engine will work OK with larger period times, IMO there is not reason not to. E.g. 50ms or more (200 ms) should make the processing stable, IMO. Raising the period time is a standard cure for these problems (if the alsa application allows configuring this parameter which is not the case of current java, unfortunately).
For 96kHz the REW generator/analyzer combo is rock solid. For 192kHz there are dropouts in the stream, making the spectrum "flicker", unable to average for any useful time.
Alsa works with two blocks - period and buffer. Period is time/buffer between two soundcard interrupts. Buffer is the block of samples used by the soundcard's DMA engine. While e.g. ASIO has hard-coded 2 periods in buffer, alsa has the number of periods within buffer configurable from 2 to whatever the driver allows.
In java the buffer size is configurable, directly related to the buffer size param in REW. Indeed, 128k of samples translate to buffer_size of the alsa driver (128k = 131072):
Code:
pavel@precision:~$ cat /proc/asound/USB/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S24_3LE
subformat: STD
channels: 2
rate: 192000 (192000/1)
period_size: 3840
buffer_size: 131072However the period size, which tells how often java thread is asked/awoken to supply/provide data, is hardcoded at 20ms (i.e. 3840 samples at 192kHz samplerate)
jdk/PLATFORM_API_LinuxOS_ALSA_PCM.c at 6bab0f539fba8fb441697846347597b4a0ade428 * openjdk/jdk * GitHub
jdk/PLATFORM_API_LinuxOS_ALSA_PCM.c at 6bab0f539fba8fb441697846347597b4a0ade428 * openjdk/jdk * GitHub
That value works OK for simple utils like aplay/arecord (which produce no xruns down to the minimum 500us period time specified by the device), but is apparently too small for processing in java.
When I work on the patch for PCM devices, I will try to make this value also configurable via some environment variable. The latency will grow, but that is no problem for use case like this. Hopefully the java audio engine will work OK with larger period times, IMO there is not reason not to. E.g. 50ms or more (200 ms) should make the processing stable, IMO. Raising the period time is a standard cure for these problems (if the alsa application allows configuring this parameter which is not the case of current java, unfortunately).
Last edited:
I thought I had answered but apparently this was not the case. I can confirm REW with 96 kHz stereo access works OK.
Also 192 kHz works fine for me on my desktop PC but not on my laptop where indeed I have dropouts and even crashes. Not sure if it's a matter of hardware or kernel / alsa / JRE version.
Also 192 kHz works fine for me on my desktop PC but not on my laptop where indeed I have dropouts and even crashes. Not sure if it's a matter of hardware or kernel / alsa / JRE version.
The period time of 20ms is very likely too low for high-latency java at 192kHz. I will add the period time env variable in my java build and see what a change does.
Hi,
In hope of doing FFT spectrum analysis, I recently bought a E-MU 0404 USB from a guitar shop in California (mail order), and of course it came with no manuals or accessories.
Is this device powered via the USB port? It shows no signs of life as yet. I note that it features a 5V power jack, but of course no ac wall wart was included--- hence, my question about powering the unit.
Can anyone point me to a source/links for manual, drivers, etc, for the USB version of the 0404? I downloaded a manual for the computer card version, but it includes no info re the USB version. Via Google searches, I've found some enticing links. One led me to the to the PCI version, not what promised. My paranoia, perhaps groundless, makes me nervous about some of the sites--- some download buttons make me think of event horizons surrounding black holes. I do not want to get sucked in. 🙁
Thank you for any advice.
In hope of doing FFT spectrum analysis, I recently bought a E-MU 0404 USB from a guitar shop in California (mail order), and of course it came with no manuals or accessories.
Is this device powered via the USB port? It shows no signs of life as yet. I note that it features a 5V power jack, but of course no ac wall wart was included--- hence, my question about powering the unit.
Can anyone point me to a source/links for manual, drivers, etc, for the USB version of the 0404? I downloaded a manual for the computer card version, but it includes no info re the USB version. Via Google searches, I've found some enticing links. One led me to the to the PCI version, not what promised. My paranoia, perhaps groundless, makes me nervous about some of the sites--- some download buttons make me think of event horizons surrounding black holes. I do not want to get sucked in. 🙁
Thank you for any advice.
Indeed you need to power it up with an external power supply. Unfortunately it's hard to understand which exact DC jack you need as they come in different sizes without much markings (I have no precision tool to measure the inner/outer diameter on mine, unfortunately).
I think one could build a dedicated USB cable to power the thing, not sure it will work as well as with a separate power supply though.
Original E-MU site is gone. Here the old product page on Archive.org. From "Support" you can retrieve the manual as well! (I also have a copy but I am not sure it's OK to upload it here because, of course, it's copyrighted material).
Hope this helps 🙂
Thank you, Interference!
I've found a plug that appears to be a mate, at least visually, so I should be able to cobble together a source. I'll explore your link.
Thanks again.
I've found a plug that appears to be a mate, at least visually, so I should be able to cobble together a source. I'll explore your link.
Thanks again.
As of the power supply - the soundcard reports 2mA consumption requirement in its USB configuration. Clearly only the USB front end is powered.
5V with nominal consumption of about 0.4A but the supply needs to support at least 0.7A. I'd also recommend using a 12V batt via heatsunk 7805 (with series diode and dropper resistor to lessen the heatsinking) if you want to avoid one mains hum entry point for low noise floor testing.
Also note the left channel noise artefacts, and use the beta driver for Win OS.
Also note the left channel noise artefacts, and use the beta driver for Win OS.
Hope this is the appropriate thread to drop in. I am fiddling for some time with linux (LMDE), ARTA, STEPS and EMU-0202 and EMU-Tracker pre.
Recently I installed Ubuntu Studio on a separate machine for comparisions. Starting loopback THD-measurements with ARTA FFT on LMDE yields the more or less usual result:
Recently I installed Ubuntu Studio on a separate machine for comparisions. Starting loopback THD-measurements with ARTA FFT on LMDE yields the more or less usual result:
