Recording the SPDIF input of M-Audio Audiophile 2496 PCI card in Audacity, how?

[tux99]

I have a M-Audio Audiophile 2496 PCI audio card that has a SPDIF coax input.

When I use 'arecord' on the command line I can record from the SPDIF input of the M2496 without any problems using the following command: arecord -D iec958:CARD=M2496,DEV=0 -c 2 -r44100 -f S32_LE xyz.wav

This means my hardware and drivers and the mixer settings are all set correctly.

Pulseaudio is not installed and Jack is not running, so just plain ALSA.

But in audacity, when I select "M Audio Audiophile 24/96: ICE1712 multi (hw:1,0)" as input device (this is the only option Audacity is showing for this card) I don't get any input level signal and therefore cannot record from the M2496.

Has anyone successfully recorded from the SPDIF input of a M2496 with Audacity?

[tux99]

I just noticed that if I set Audacity to record 12 tracks (instead of 'stereo') it will record the SPDIF input on tracks 9 and 10 and on tracks 11 and 12.

So it seems I have to record all 12 virtual tracks of the M-Audio 2496 and then just delete all empty unwanted tracks?

Is there no way with Audacity to record just the left and right SPDIF tracks, like with 'arecord'?

And why do I get the left and right SPDIF tracks twice (tracks 9 and 10, and 11 and 12)?

[tux99]

Found this thread about the same subject on the linux-audio-user mailing list:
https://lists.linuxaudio.org/pipermail/ ... html#98263

Looks like this is a problem/limitation of the portaudio library which Audacity uses.

With Mhwaveedit I have no problems recording just the SPDIF input as stereo channel pair (using 'iec958:M2496' as recording device in the sound preferences of Mhwaveedit)

[j_e_f_f_g]

have to record all 12 virtual tracks of the M-Audio 2496

Yep. To save money and R+D time, MAudio used a lot of the same circuitry in a whole bunch of their PCI cards. One of things they did is use a generic chip that feeds the 10 DACs of the DELTA 1010 and DELTA LT. This chip must be fed 10 channels of audio data regardless of whether you actually have 10 DACs attached to it. The 2496 uses only channels 1 and 2 (analog pair #1) and channels 9 and 10 (the SPDIF). I don't know why there's a duplication on 11 and 12. In fact, as I recall, the 2496's chip has 10 channels, not 12. Maybe Audacity is doing the duplication because you asked for 12 channels, and ALSA tells audacity that the card has only 10.

Anyway, the reason why I know this is because I have a 2496, and when I started writing BackupBand, I discovered that ALSA would give me an error if I tried opening only 2 channels. I discovered I had to open 10 channels, and just feed channels 3 to 8 with anything -- didn't matter since they weren't attached to anything. So I designed BackupBand to accomodate hardware like this so that. If the user wants 2 chans, but alsa tells me the minimum I can take is 10 (and alsa does in fact tell you that -- audacity should have reported that to you. I hate apps that omit error checking/reporting. I'm anal-retentive about that in my apps), then I just service those extra chans (throwing away their incoming 0 data words) while letting the user think he's just getting 2 chans. Obviously, audacity ain't written to accomodate that. Not a fan of that app.

So here's the kicker. I originally wrote backupband for Windows. And there I had no problem getting 2 chans from the driver. How? Because the Windows driver does exactly what I was doing in BackupBand for Linux. It secretly/silently services those extra useless chans. The linux 2496 driver doesn't. Why not? Couple of reasons. MAudio wrote an individual Windows audio driver for each of its PCI cards (ie, the 2496 driver doesn't really "work" with chans 3 to 8, whereas the Delta 1010 driver does since there's real hardware there). But there is no 2496 linux driver. There is no Delta 1010 linux driver. There is no Audiophile linux driver. Etc. There are no individual drivers to handle the quirks/differences between models. There is just one alsa generic "one-Maudio-size-fits-all" driver to handle all these models that have the same chip -- the "ice-bla-bla-something" driver. And let's say the guy who wrote it... um.... ah.... (here's where the linux advocates get mad at me for telling it like it is)... the guy owns a Delta 1010, and ain't earning a penny off the difficult skill of writing a device driver. Might he not reasonably think?...

I'm not going to do all this work of making individual drivers. Hell no, not for free. And all I personally need is a Delta 1010 driver anyway. I don't own these 6 other MAudio cards. But it just so happens if I accept some lowest common denominator -- in this case a minimum of 10 chans -- I can make my driver work with all 7 maudio pci cards, with minimal effort. This generic driver will work better with certain models, like my 1010, and not so good with a 2496. But it's acceptable free labor, and the driver does "work" with 7 models. Just like how the generic emu linux driver "works" for a whole bunch of Creative Labs cards including the fancy DSP 24-bit emu 1212 (16-bit only, no dsp effects... shhh don't tell any one -- the alsa web site says its "supported").

But I know someday there's gonna be a guy who recorded 2 audacity tracks on Windows for years. He's gonna fire up audacity on linux, and suddenly his 2 tracks ain't working. He'll probably never know why.

But maybe, possibly, probably not, there will be a former Windows dev who will be so frustrated by how badly designed and erratic some of this linux free stuff is, and how poorly it's documented, he'll do something insane like a 6 month code review of the alsa kernel sources just to see what it actually does. So when asked...

Is there no way to select just the left and right SPDIF tracks?

... this lunatic will write a boring detailed screed about how/why things are in alsa/jack world, and end with the snide wisecrack...

Not unless you go back to Windows, or find less crappy linux software. (Hint: not audacity.)

And frankly Scarlett, I don't give a damn... because my Delta 1010 works.

[tux99]

Jeff thanks for your reply but the problem is not the linux ALSA driver as I can select and record only the two SPDIF channels just fine when using ALSA directly with 'arecord' or even with 'mhwaveedit'.

The problem is in the portaudio library that Audacity unfortunately uses. I did notice other problems with portaudio in one other application using the onboard sound too, to me it seems that portaudio has general deficiencies when it comes to detecting available audio devices on Linux.

Anyway, I sort of have solutions now (either use 'mhwaveedit' or record all channels with Audacity and then delete the unwanted ones).

[j_e_f_f_g]

not the linux ALSA driver as I can select and record only the two SPDIF channels

arecord is doing what BackupBand does. You ask the app for 2 chans. Alsa driver says "Sorry it's 10 channels or nothing." So the app replies "THen gimme 10 chans. As the data (0 values or "digital silence") is pouring in for chans 1 to 8, I'll throw it away as fast as I can. I'll give the user only chans 9 and 10 like he asked. And he'll never know what I had to do to get it."

Of course the Windows driver does this hack on its own because why the hell would any app want 6 chans of perpetual silence?? Crap like that would have killed 2496 sales.

The linux driver doesn't. Because 10 chans is fine for the developer's 10 in, 10 out Delta 1010. And this driver "supports" your 2496.

So now every single linux app has to do this same hack... over and over. Or not, as in audacity's case. Which means you have to deal with 6 phantom chans.

It's the pervasive nature of lowest-common-denominator, one-size-fits-all, half-finished linux support that drives ne nuts. There are times when I want to scream at some OSS dev:

"DON'T RELEASE THAT!! I realize you're attempting to fill a void, and your intent may be good. But what you've produced is so ill-advised that it will ultimately cause more problems than it solves, so poorly documented that it'll be misused and maybe destructive, and is such an overreaching, ungodly mess that after you burn out on it, no one else will ever pick up support for it. It will just stink up the place for years. So don't do it!"

There are days when I feel that way about ALSA and JACK.

[tux99]

not the linux ALSA driver as I can select and record only the two SPDIF channels

arecord is doing what BackupBand does. You ask the app for 2 chans. Alsa driver says "Sorry it's 10 channels or nothing." So the app replies "THen gimme 10 chans. As the data (0 values or "digital silence") is pouring in for chans 1 to 8, I'll throw it away as fast as I can. I'll give the user only chans 9 and 10 like he asked. And he'll never know what I had to do to get it."

I'm pretty sure you are mistaken. 'arecord' is a very simple program, it does not have special treatments for specific cards.

The ALSA driver explicitly exports the iec958 device for the M2496, and that device provides only 2 channels, so the driver does the filtering out, not 'arecord'. As I said, it's the same for Mhwaveedit, all I had to do was set 'iec958:M2496' as recording device in the sound preferences of Mhwaveedit and it also only records 2 channels.

The problem is that the portaudio library (used by Audacity) ignores the iec958 device for some reason, just like it ignores and misinterprets several analog devices from my onboard audio chip (an ordinary ALC888).

[j_e_f_f_g]

oh tux... alsa's arecord doesn't use mmap mode (direct read/write to the hardware's dma buffer), unlike audacity and jack and backupband do! arecord uses alsa's snd_pcm_read functions, which sit on top of alsa's buffer conversion, data format conversion, and resampler! It's alsa software converters doing that manipulation I described above to give you 2 chans.

That iec958 "device" is the maudio alsa driver telling the software converters what settings to use, to accomodate the hardware. In other words, it''s just "plughw" (the software converters) configured with the drivers settings. And given a name so an app can open this maudio-specific instance of plughw.

But mmap mode bypasses all software converters/devices to go directly to the hardware dma buffer.

portaudio uses mmap mode. That's why it ignores a software layer that's irrelevant. And for pro audio, you don't want to use "iec958".

Someday I should write up a tech paper on alsa. There's so much ambiguity and confusion surrounding it.

[Digital Black]

... if you don't mind, how can I make Delta 1010LT's s/pdif input working with ALSA/Jack? I didn't quite follow the above explanation, I'm just a musician and soundtech, eh. I have tried almost all but no success. I understand that this is an ageing card and writing code for free may not be so rewarding.

[j_e_f_f_g]

Using QJackCtl, set the number of inputs and outputs to 10. Channels 1 and 2 are the main Left/Right analog inputs/outputs. Channels 9 and 10 are the SPDIF.

[Digital Black]

Here is what I get when I/Os set from default to 10.

Code: Select all

07:00:54.290 Statistics reset.
07:00:55.123 ALSA connection change.
connect(2) call to /dev/shm/jack-1001/default/jack_0 failed (err=Tiedostoa tai hakemistoa ei ole)
attempt to connect to server failed
07:00:55.882 ALSA connection graph change.
07:06:38.792 JACK is starting...
07:06:38.793 /usr/bin/jackd -v -t2000 -m -dalsa -r48000 -p256 -n2 -Xraw -D -Chw:M1010LT -Phw:M1010LT -i10 -o10
connect(2) call to /dev/shm/jack-1001/default/jack_0 failed (err=Tiedostoa tai hakemistoa ei ole)
attempt to connect to server failed
jackd 0.124.2
Copyright 2001-2009 Paul Davis, Stephane Letz, Jack O'Quinn, Torben Hohn and others.
jackd comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
07:06:38.804 JACK was started with PID=2164.
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_oss.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_alsa_midi.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_net.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_alsa.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_dummy.so
getting driver descriptor from /usr/lib/x86_64-linux-gnu/jack/jack_firewire.so
JACK compiled with System V SHM support.
server `default' registered
loading driver ..
apparent rate = 48000
creating alsa driver ... hw:M1010LT|hw:M1010LT|256|2|48000|10|10|nomon|swmeter|-|32bit
configuring for 48000Hz, period = 256 frames (5.3 ms), buffer = 2 periods
ALSA: final selected sample format for capture: 32bit integer little-endian
ALSA: cannot set channel count to 10 for capture
ALSA: cannot configure capture channel
cannot load driver module alsa
registered builtin port type 32 bit float mono audio
registered builtin port type 8 bit raw midi
clock source = system clock via clock_gettime
new client: alsa_pcm, uuid = 8589934593 type 1 @ 0x1741a80 fd = -1
starting server engine shutdown
freeing shared port segments
stopping server thread
start poll on 3 fd's
last xrun delay: 0.000 usecs
max delay reported by backend: 0.000 usecs
freeing engine shared memory
max usecs: 0.000, engine deleted
cleaning up shared memory
cleaning up files
unregistering server `default'
no message buffer overruns
07:06:38.998 JACK was stopped
07:06:38.998 Post-shutdown script...
07:06:38.998 /usr/bin/stop_jackutils.sh
a2jmidid: ei prosesseja
jackd: ei prosesseja
07:06:43.456 Post-shutdown script terminated with exit status=256.
07:06:44.867 Could not connect to JACK server as client. - Overall operation failed. - Unable to connect to server. Please check the messages window for more info.
connect(2) call to /dev/shm/jack-1001/default/jack_0 failed (err=Tiedostoa tai hakemistoa ei ole)
attempt to connect to server failed

[fraslo]

Here is what I get when I/Os set from default to 10.

Code: Select all

ALSA: cannot set channel count to 10 for capture

Same card and same error here. But it is not necessary to set this parameter. Leaving it on "Default" creates 12 input channels. Just try to record channel 9+10 or 11+12 using jack. I can not test this here because I am using the analog input.

Frank

[Digital Black]

On the Envy24 Control Utility/ Hardware Settings, it still says "IEC958 input status: Unable to read IEC958 input status: no such file..."
So, on my book this says that something is wrong with that control app.

@frasio, yes I have tried it with defaults but no signal has appeared.

[tux99]

You need to check the following setting in the Envy24 Control Utility in the hardware settings tab:
Master Clock should be S/PDIF IN

[Digital Black]

You need to check the following setting in the Envy24 Control Utility in the hardware settings tab:
Master Clock should be S/PDIF IN

Showstopper, huh? That it is. It takes the jack down and no audio until reboot.