E-MU 0404 and Linux (also issues with capture at 96 kHz)
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.
I recommend using the REW forum - sometimes there are bugs (John is amazing at how he continues to advance features and take note of bugs). The forum may have some comment already, and using the latest beta version is pretty much the best way to go.
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 :/
REW is in java, that would be a problem with java alsa native code. IMO if a problem exists, it will be directly in EMU driver.
My 0404 USB is on the way, I will have to make it work somehow for my project.
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.
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.
I really cannot tell without examining the card and its loaded driver stack first. The card should arrive on Tuesday. Hopefully not a bad deal for 35 EUR pre-owned...
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 :)
Try install "pavucontrol" a audio control interface Here maybe to get a better overview
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.
|All times are GMT. The time now is 07:26 PM.|
Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 17.65%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2019 DragonByte Technologies Ltd.
Copyright ©1999-2019 diyAudio