need proper support for Terratec EWS88-MT (ice1712)

[aelschuring]

I understand that this is probably one of the most difficult cards to support, but since some update after 0.9.15 completely broke the card I'm filing an official request :)

I have been using PA since 0.9.10 (first Ubuntu, now Debian), and have never really have issues with it apart from me having to manually configure my device:

load-module module-alsa-sink sink_name=ews88_out device=hw:0 channels=8 channel_map=left,right,aux0,aux1,aux2,aux3,aux4,aux5

load-module module-alsa-sink sink_name=ews88_system_out device=hw:0,2 channels=2 channel_map=left,right

module-hal-detect doesn't work because it will only recognize the s/pdif output, and that is exactly the one I don't use.

The current issue I'm facing is that since Debian release 0.9.15-4.1, the above module-alsa-sink lines no longer work, and PA crashes at startup. When I remove the module-alsa-sink lines and enable module-hal-detect, PA starts but only offers the auto-null sink. The same behaviour is displayed by 0.9.16~test2~20090726git59659e1db-1 from Debian experimental. Version 0.9.15-2 is the one I'm currently using and that still works.

I filed two debian bugreports but I don't think they ever made it here:

http://bugs.debian.org/529290 -- missing profiles

http://bugs.debian.org/540388 -- no sinks

Information about the card: this card has three independent audio devices that can be used simultaneously:

hw:0,0 8-channel In and Out

hw:0,1 2-channel s/pdif In and Out

hw:0,2 2-channel Out

[aelschuring]

PA 0.9.15 choking on the module-alsa-sink lines

[aelschuring]

PA with stock configuration; starts with auto-null sink

[lennart]

Please don't compress attachments. It's really hard to read them if you do.

[lennart]

Also, please don't use the bare hw:xxx devices. Access the card via the high-level "front:xxx", "spdif:xxxx", "surround71:xxx" device strings instead.

Could you please retry with 0.9.16-test4? Some drivers seem to have issues with the order in which buffer/frag size is configured. This is turned around in test4.

Finally, for cards that have multiple independant outputs or multiple independant inputs 0.9.16 now introduces the ability to define the set of exposed profiles via config files. Please read up on this here:

https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004229.html

I'd be happy to add a profile set specifically for your card to the set we already ship like those for the Audio4DJ cards:

http://git.0pointer.de/?p=pulseaudio.git;a=tree;f=src/modules/alsa/mixer/profile-sets

[lennart]

Hmm, you said "and PA crashes at startup". I see now crash in those logs. Only clean handling of errors? Where's therea crash?

[aelschuring]

Replying to lennart:

Also, please don't use the bare hw:xxx devices. Access the card via the high-level "front:xxx", "spdif:xxxx", "surround71:xxx" device strings instead.

I would, but there is no surround71 device for this card and not a single device that maps to hw:0,2. What would be the difference between front0 and accessing hw:0 with 2 channels?

Could you please retry with 0.9.16-test4? Some drivers seem to have issues with the order in which buffer/frag size is configured. This is turned around in test4.

Yep, seems fixed: it also adds more profiles (digital surround IEC), but still only spdif profiles. module-alsa-sink also appears to work, but it configures 10/12 out/in channels even though the load-module line says channels=8. Using device front:0 (without a channel map) gives me the same 10/12 channel options.

Finally, for cards that have multiple independant outputs or multiple independant inputs 0.9.16 now introduces the ability to define the set of exposed profiles via config files. Please read up on this here: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004229.html I'd be happy to add a profile set specifically for your card to the set we already ship like those for the Audio4DJ cards: http://git.0pointer.de/?p=pulseaudio.git;a=tree;f=src/modules/alsa/mixer/profile-sets

Quite some text. I'll see what I can find and let you know. One question immediately comes up: where should I put this configuration? In a new file in /etc/pulse, in ~/.pulse? Do I need to load-module it manually, or will it be auto-detected based on extension or filename?

Hmm, you said "and PA crashes at startup". I see now crash in those logs. Only clean handling of errors? Where's there a crash?

You're right, technically it's not a crash. But PA failing to initialize the sink and exiting cleanly still has about the same result...

[lennart]

Replying to aelschuring:

I would, but there is no surround71 device for this card and not a single device that maps to hw:0,2. What would be the difference between front0 and accessing hw:0 with 2 channels?

Then that's the problem here. If front:xxx does not work then please make sure that this gets fixed by ALSA. The autoconfiguraton n PA relies on front:xxx, surround51:xxx and friends to be available.

Could you please retry with 0.9.16-test4? Some drivers seem to have issues with the order in which buffer/frag size is configured. This is turned around in test4.

Yep, seems fixed: it also adds more profiles (digital surround IEC), but still only spdif profiles. module-alsa-sink also appears to work, but it configures 10/12 out/in channels even though the load-module line says channels=8. Using device front:0 (without a channel map) gives me the same 10/12 channel options.

Your front:xxx device is broken. It's supposed to support only 2ch. A front:xxx device that only knows 10/12 channels makes no sense. Please make sure to get this fixed in ALSA.

If you ask for 8 channels but the underlying alsa drver refuses to do that PA will pick the next channel setting that is supported, if you use module-alsa-sink directly.

Finally, for cards that have multiple independant outputs or multiple independant inputs 0.9.16 now introduces the ability to define the set of exposed profiles via config files. Please read up on this here: https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004229.html I'd be happy to add a profile set specifically for your card to the set we already ship like those for the Audio4DJ cards: http://git.0pointer.de/?p=pulseaudio.git;a=tree;f=src/modules/alsa/mixer/profile-sets

Quite some text. I'll see what I can find and let you know. One question immediately comes up: where should I put this configuration? In a new file in /etc/pulse, in ~/.pulse? Do I need to load-module it manually, or will it be auto-detected based on extension or filename?

You need to place them in the same dir as the audio4dj files and make sure to add a rule to /lib/udev/rules.d/90-pulseaudio.rules so that the profile set is properly detected for your devce. You need to be careful there however, since quite a few devices are based on the ice1712 chip, so you must make sure that your file only matches against the Terratec model.

[aelschuring]

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4671

I can't easily test profiles, because when I use module-udev-detect instead of module-hal-detect, I only get the null sink again:

D: cli-command.c: Checking for existance of '/usr/lib/pulse-0.9.16/modules/module-udev-detect.so': success I: module-udev-detect.c: Loaded 0 modules. I: module.c: Loaded "module-udev-detect" (index: #4; argument: "").

But this may be because I pulled pulseaudio-module-udev in from Ubuntu, as debian doesn't ship it yet. Also, there is no rules.d/90-pulseaudio.rules on my system. It will not be until this weekend that I really have the time to dig deeper.

[lennart]

Replying to aelschuring:

https://bugtrack.alsa-project.org/alsa-bug/view.php?id=4671

Good luck with that. Unfortunately the ALSA BTS doesn't get the interest from the right people it deserves.

But this may be because I pulled pulseaudio-module-udev in from Ubuntu, as debian doesn't ship it yet. Also, there is no rules.d/90-pulseaudio.rules on my system. It will not be until this weekend that I really have the time to dig deeper.

Uh, uh. I wouldn't be surprised if the Ubuntu packages are broken in this respect. Also, you need at least udev 143 for this to work. And a kernel with the deprecated syfs stuff disabled. I doubt Debian's version qualifies.

[aelschuring]

tentative profile configuration for EWS88. Not tested

[aelschuring]

I've not yet tried a manual compile of udev. Is there a way that I can get PA to test the attached profile without going through udev?

I've added the following lines to the rules file, but again, not tested yet:

# can't match vendor or device, because it is 1412:1712 and matches all ICE1712 cards
SUBSYSTEMS=="pci", ATTRS{subsystem_vendor}=="0x153b", ATTRS{subsystem_device}=="0x1115", ENV{PULSE_PROFILE_SET}="terratec-ews88-mt.conf"
# 1115 and 1125 is the same card, but multi-card configuration (MASTER mode)
SUBSYSTEMS=="pci", ATTRS{subsystem_vendor}=="0x153b", ATTRS{subsystem_device}=="0x1125", ENV{PULSE_PROFILE_SET}="terratec-ews88-mt.conf"

[lennart]

You should be able to place that in a file in /lib/udev/rules.d/90-pulseaudio.rules (copy the original from git). And then try it out with "udevadm trigger -ssound" and then check with "udevadm info -qall -p /sys/class/sound/card0/".

The profiles file looks good to me, though I'd probably not use front:xxx at all anymore. The profiles file does basically what "front:xxx" is supposed to do: map some logical meaning to the raw hw:xxx devices. And if we do this then we we should probably go all the way and use hw:xxx everywhere.

[lennart]

Also, instead of compiling yourself I'd suggest getting the development versions of Ubuntu's packages or the PPAs.

[aelschuring]

Ok, installed udev-145 from Ubuntu. I'm already running a custom kernel, so that should be fine. Udev plays along nicely, and module-udev-detect appears to be working as well.

aschuring@neminis:/tmp/tst$ /sbin/udevadm info -qall -p /sys/class/sound/card0/
P: /devices/pci0000:00/0000:00:0c.0/sound/card0
E: UDEV_LOG=3
E: DEVPATH=/devices/pci0000:00/0000:00:0c.0/sound/card0
E: SOUND_INITIALIZED=1
E: ID_VENDOR_FROM_DATABASE=VIA Technologies Inc.
E: ID_MODEL_FROM_DATABASE=ICE1712 [Envy24] PCI Multi-Channel I/O Controller
E: ID_BUS=pci
E: ID_VENDOR_ID=0x1412
E: ID_MODEL_ID=0x1712
E: ID_PATH=pci-0000:00:0c.0
E: SOUND_FORM_FACTOR=internal
E: PULSE_PROFILE_SET=terratec-ews88-mt.conf

aschuring@neminis:/tmp/tst$ ls -1 /usr/share/pulseaudio/alsa-mixer/profile-sets/
default.conf
native-instruments-audio4dj.conf
native-instruments-audio8dj.conf
terratec-ews88-mt.conf

aschuring@neminis:/tmp/tst$ grep SYSFS /boot/config-2.6.31-rc6 
# CONFIG_SYSFS_DEPRECATED_V2 is not set
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_RTC_INTF_SYSFS=y
CONFIG_SYSFS=y

But... the profile-set does not appear to be read: there is no mention of it in the log, not even at -vvv. The end result is that I only get the iec958-profiles, similar to when I was using module-hal-detect. What am I missing here?

[aelschuring]

pulseaudio -vvv log using module-udev-detect and up-to-date udev

[aelschuring]

ok, forget that, I've already found why: the PULSE_PROFILE_SET variable is not parsed in module-udev-detect, it's from module-alsa-card. And since that's still Debian's, it's compiled without udev support...

So now I have all of PA from Ubuntu, and the profile-set gets discovered automatically. I'll play some more with the profiles and upload the final version.

[aelschuring]

This is the configuration that I'm currently using. Some caveats:

• hw:0,1 appears to work, but does not produce output on any port. So I've resorted to using iec958:0, which does work but which cannot be accessed simultaneously with hw:0,0 . This is not a PA problem, since aplay can't do it either: aplay: pcm_write:1528: write error: Input/output error
• any channel configuration other than the 12in/10out will result in ALSA errors, so I've removed every attempt at an "all stereo" configuration
• I've not added profiles for more exotic digital output configuration like ac3 passthrough or a52 recoding, it can probably be done (the card supports spdif "data" mode) but I can't test it.

This gives me 3 working outputs (but not all simultaneous) and live stream migration between all of them (via profile switching). There is still a (minor) mixer-path issue because when I mute the system-out port with alsamixer I cannot unmute it with pavucontrol, but at least the current profiles work...

[ianc]

Replying to aelschuring: Thanks guys - this solution works also for the M-Audio 2496.

The appropriate entry in /lib/udev/rules.d/90-pulseaudio.rules is:

SUBSYSTEMS=="pci", ATTRS{subsystem_vendor}=="0x1412", ATTRS{subsystem_device}=="0xd634", ENV{PULSE_PROFILE_SET}="M-Audio_2496.conf"

With M-Audio_2496.conf being per the ews88 one - is it worth making this "ICE1712.conf" or similar since it is (or should be) be generic for this chipset?

[aelschuring]

Replying to ianc:

With M-Audio_2496.conf being per the ews88 one - is it worth making this "ICE1712.conf" or similar since it is (or should be) be generic for this chipset?

That depends... How many channels does your primary output device have? I'm guessing here, but I suspect that you're using the src_*.conf file that I attached a few days ago, and that your profile is called "Stereo Output On All Channels"? In that case we can't use the same configuration: I had to kill that profile because it wouldn't work on my card.

If, on the other hand, you're able to choose a profile that says "8-Channel Output", and PA gives you a main output device with 10 channels, then yes, we could probably use the same profile for all ICE1712-based cards.

Problem is, I'm not knowledgeable enough about the ICE chip to really make a sensible judgement on what to do: according to the ALSA sources, there are cards on the market with all kinds of channel configurations: 8in/8out (mine), 2/2 (yours?), 4/4, 0/4, 2/8, 6/6. Some cards support a separate S/PDIF device, some don't. If we can support all those with a single profile-set because ALSA always exposes a 12in/10out main device regardless of how many channels are actually connected, then we could suffice with one profile-set (but it would make ALSA horribly broken in my eyes). Otherwise it would be better to create a separate configuration file for cards that we can actually test, like yours and mine.

So: how many devices and channels does your card have, and what profiles can you choose when you use my conf file?

[ianc]

Replying to aelschuring: No - the file you posted a few days ago was useless for me also. I'm using the file you posted yesterday - *all* I have done is rename it. In pavucontrol I'm seeing five profiles (ignoring "Off") and these are (top to bottom):

8-Channel Output, 8-Channel Input

Digital Input/Output (8-Channel Disabled)

8-Channel Output Active

Digital Output Only

System Output Only

Which is precisely what you'd expect from the priority settings in your .conf file - in other words my card seems to be - at least as far as ALSA & Pulseaudio are concerned - identical to yours.

I agree though - I for sure don't know enough to state that all cards with this chipset will behave the same.

Good news though - at least two seem to!

[lennart]

aelschuring: could you change the udev rules to match against both vid/pid *and* the subsystem ids? DOesn't seem right to me to check just the subsystem ids.

Hmm, what's /proc/asound/pcm saying about your device? Do you know what device 0 resp. 1, 2 are actually supposed to do on your card? Somone mentioned that spdif was always on the uppermost channels even if you open as hw:0,0. Is that true? You said, you don't know what ,1 is good for, right? Do you know what ,2 is good for?

Otherwise the profile set file looks pretty good to me.

The mixer path can be reconfigured flexibly, too. What's the name of the mixer element in question?

ianc, the big problem here is that while various cards use the same chip here they use it in vastly different ways. i.e. there are consumer cards, semi-pro and pro-cards using the same chip. Some expose different connectors than others, some label them differently (i.e. as in "do you connect rear center to channel 3 or channel 5?"). The point of the profile set logic here is to expose exactly what is supported in various sensible configurations and label it neatly.

So, before we merge this profile set definition and activate it for both you your cards I'd like to make sure that the cards actually have the same ports, labeled the same way in the same order. Could you both please list that exactly here? Thanks!

[aelschuring]

generic profile set for ICE1712, assuming that ALSA exposes the same channels on every card, regardless of its physical configuration

[aelschuring]

Replying to lennart:

aelschuring: could you change the udev rules to match against both vid/pid *and* the subsystem ids? DOesn't seem right to me to check just the subsystem ids.

Yes, that seems logical. Done.

Hmm, what's /proc/asound/pcm saying about your device? Do you know what device 0 resp. 1, 2 are actually supposed to do on your card? Somone mentioned that spdif was always on the uppermost channels even if you open as hw:0,0. Is that true? You said, you don't know what ,1 is good for, right? Do you know what ,2 is good for?

Yes, I was already suspecting something like that. I don't know for sure, but it makes sense that spdif would be at channels 8+9 of 0,0. hw:0,2 is the separate "monitor" jack, a single stereo output. The only thing I can think of is that hw:0,1 is ALSA's abstraction of the virtual mixer deck (the card allows you to route /any/ of the 8 inputs and outputs to a separate "digital mixer" track, with its own hardware volume controls - very useful for mixing and sampling)

I can give you asound/pcm, but I'm afraid it won't help you much:

$ cat /proc/asound/pcm
00-00: ICE1712 multi : ICE1712 multi : playback 1 : capture 1
00-01: ICE1712 consumer : ICE1712 consumer : playback 1 : capture 1
00-02: ICE1712 consumer (DS) : ICE1712 consumer (DS) : playback 6

There are two other outputs that I will attach later, they give much more information about the card:

$ amixer -c0 scontents
$ find /proc/asound/card0 -name info -exec head -n100 '{}' \+

The mixer path can be reconfigured flexibly, too. What's the name of the mixer element in question?

There are two: Master and PCM, and they both only affect hw:0,2 (the "monitor" mini-jack). Neither are affected by the volume slider in pavucontrol.

ianc, the big problem here is that while various cards use the same chip here they use it in vastly different ways. i.e. there are consumer cards, semi-pro and pro-cards using the same chip. Some expose different connectors than others, some label them differently (i.e. as in "do you connect rear center to channel 3 or channel 5?"). The point of the profile set logic here is to expose exactly what is supported in various sensible configurations and label it neatly.

If I googled correctly, then his card shouldn't support multi-channel at all: it only has a stereo output (and a digital output). But given your previous comment, it might make some sense: his analog output is at channels 0+1, and the digital output is (probably hardcoded by the chip) at channels 8+9. His card just has no use for the channels in between...

[aelschuring]

EWS88: output of find /proc/asound/card0 -name info -exec head -n100 '{}' \+

[aelschuring]

EWS88: output of amixer -c0 scontents

[aelschuring]

I can confirm Lennart's suspicions about the channel layout: spdif is indeed located at the two topmost channels of hw:0,0. I can use them by specifying the following channel map:channel-map = aux0,aux1,aux2,aux3,aux4,aux5,aux6,aux7,front-left,front-right

And I can even get simulaneous outputs on analog+digital by specifying front-X twice in the channel map... Lennart, can/does PA allow me to specify multiple separate stereo channels in the channel map? What I'm looking for, is the ability to specify something like this:

[Mapping analog-stereo-pairs]
description = Analog Multi-Channel Split In Stereo Pairs
device-strings = hw:%f,0
channel-map = front1-left,front1-right,front2-left,front2-right,front3-left,front3-right,front4-left,front4-right,front5-left,front5-right
direction = input

And then have PA offer me five separate stereo sinks...

I don't really have a use case for five separate sinks... but the ability to offer two sinks (one analog, one digital) in the same profile would be really awesome...

pretty please? :)

[ianc]

OK - I'm starting to get my head around this now. Yes the M2496 has just the 2 channels + digital, but it seems that the channels it does have are mapped in the same places as they are on the multi channel card & also that it (so far anyway) cleanly ignores the ones it has no use for. So the via-ice1712.conf attached yesterday does work (I've tested analog in & out and digital out - no way to check digital in at the moment):

- I get input/outputs as expected for the various Multi-Channel & Digital profiles.

- If I select "System Output Only" then I get the same outcome as for "Off", which is reasonable since this card has no monitor output.

Also I confirm that spdif does appear as the two topmost channels of hw:0,0 in the same way as for the EWS88 and that the simultaneous analog+digital output trick works.

[aelschuring]

Revised patch: better channel map support and working analog+digital profile

[aelschuring]

This patch adds support for the M2496, based on the comments by ianc

[aelschuring]

Also I confirm that spdif does appear as the two topmost channels of hw:0,0 in the same way as for the EWS88 and that the simultaneous analog+digital output trick works.

Thanks for your help. Could you please test the profile for your card (in second patch)? I've removed all references to multi-channel configurations and removed the system-out sink, beyond that not much has changed.

If you have a standard RCA (cinch) cable, you could test the digital-in by connecting the digital-out of the card to the digital-in, and then checking the volume levels in pavucontrol. It's not a substitute for real audio tests, but at least we know if the channel mappings are correct. It's the only way for me to test the digital-in as well.

Also, could you still provide the output of $ cat /proc/asound/pcm?

[ianc]

Output of cat /proc/asound/pcm

[ianc]

The M_Audio-Audiophile-2496 patch works OK for me (thanks) since I only need outputs.

I can't get the spdif input to work via loop-back with any mapping I've tried so far (and haven't been able to test with an external input - I do have one, but it's not to hand at the moment and won't be for 2-3 weeks minimum). However I haven't succeeded in getting it to work with just ALSA either, so it is possible that there is no problem within Pulseaudio.

The output of $ cat /proc/asound/pcm is now attached above.

[lennart]

Hmm, I am not really happy enough with this to merge this, because the channel maps of the sinks include channels that are basically unused. They should not appear in the UI, but they will if you use the profile sets like this.

I think we should first make sure that ALSA gets fixed to include some high-level device strings that actually work properly on these devices. I.e. a "front:xxx" definition that provides two channels. and so on, for multichannel. In fact a patch for this was already posted a while back on alsa-devel, but nobody faught this through to the end. Maybe someone wants to pick this up again and push through with this?

And then, after that we can look into making use of this for proper profiles in PA.

[lennart]

Also see:

https://bugzilla.redhat.com/show_bug.cgi?id=499435

[jisakiel]

Don't know if it helps; I'm experiencing the same problems on debian with 2.6.30-1-amd64 and pulseaudio 0.9.18-1, hardware being a Terratec DMX6Fire 24/96 (also ice1712 based). Works wonderfully if I add the following to default.pa:

load-module module-alsa-sink sink_name=DMX6Fire_out device=hw:DMX6Fire format=s32le channels=10 channel_map=front-left,front-right,rear-left,rear-right,center,lfe,aux4,aux5,aux6,aux7

I can provide any other info if wanted or useful, although I don't use the card that much right now, as it doesn't really support suspend (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/93273), at least until I manage to get snd-ice1712 to unload and reload between suspends.

// (I agree, though, that alsa should provide working definitions for the card, as managing to get a working asound.conf -which I no longer use thanks to pulse- was really daunting) //

[aelschuring]

Replying to lennart:

https://bugzilla.redhat.com/show_bug.cgi?id=499435

Thanks for the link. Of course, I only started to read that one after I had searched the Alsa-devel mailing archives :|

With the patch from http://thread.gmane.org/gmane.linux.alsa.devel/59481/focus=59672 , I can get ALSA to offer a true two-channel front device, and have pulseaudio use it succesfully:

I: source.c: Created source 0 "alsa_output.pci-0000_00_0c.0.analog-front-out.monitor" with sample spec s16le 2ch 44100Hz and channel map front-left,front-right

The problem is - and that is very much the same issue as debated in the thread above - that the ICE1712 cards basically offer five separate stereo output channels, and six separate stereo input channels. That's a multi-channel configuration that does not fit in the whole "surround sound"-oriented multi-channel definition, and I'm not sure how we should want those channels to be exposed. Compounding the issue is that not all cards based on this chip have the same number of outputs...

It is fairly trivial to create a patch to alsa-lib that at least fixes the front: device, but I'm not sure how to address other configurations, especially when considering the fact that two-channel cards based on this chip also exist.

[lennart]

Replying to aelschuring:

It is fairly trivial to create a patch to alsa-lib that at least fixes the front: device, but I'm not sure how to address other configurations, especially when considering the fact that two-channel cards based on this chip also exist.

Supporting "front:" properly would be at least a good first step. Supporting "spdif:" should be doable as well.

May the different flavours of ICE cards be duistingished by their PCI subsys id?

If the channel order of the multichannel streams is not defined it would be useful to introduce alsa device strings that fix the channel number at least: "fourch:xxx", "sixch:xxx" or so might make sense? If we had that we could make use of that and offer the user different channel orders to drive his ICE card with.

[aelschuring]

I've posted a patch on alsa-devel today to at least get the patch for front:0 merged. I'm also experimenting with a solution that will allow PA and other applications to access front: and spdif: at the same time, which is currently not possible because any access to one of the channels will cause the entire device to be locked. That's a fundamental property of ALSA, and I think any solution I can come up with will be hackish.

Is there a difference between the iec958: and spdif: devices? Because currently the card defines only the first of the two.

We could probably ask for fourch: and sixch: definitions, but I don't think the ALSA guys will really like them. At least they do make more sense than surround* definitions, but there is just one minor issue: ALSA uses one configuration file for all ice1712 cards (no subsystem-id separation possible in ALSA), so I'm really hoping to keep that file as generic as possible: I'm currently leaning towards only three devices, which are front:, spdif: and an all-channel (8) definition.

[lennart]

Replying to aelschuring:

I've posted a patch on alsa-devel today to at least get the patch for front:0 merged. I'm also experimenting with a solution that will allow PA and other applications to access front: and spdif: at the same time, which is currently not possible because any access to one of the channels will cause the entire device to be locked. That's a fundamental property of ALSA, and I think any solution I can come up with will be hackish.

Depending on something like dmix for this woulde certainly be suboptimal. I must really say the ICE1712 design is really awful. ;-)

Is there a difference between the iec958: and spdif: devices? Because currently the card defines only the first of the two. We could probably ask for fourch: and sixch: definitions, but I don't think the ALSA guys will really like them. At least they do make more sense than surround* definitions, but there is just one minor issue: ALSA uses one configuration file for all ice1712 cards (no subsystem-id separation possible in ALSA), so I'm really hoping to keep that file as generic as possible: I'm currently leaning towards only three devices, which are front:, spdif: and an all-channel (8) definition.

But it sucks a bit that you have to open an 8ch stream on a device that only has 4ch plugs actually soldered on.

But then again, at some level we need to add the additional null channels. And I guess that work should be done at one place and one place only. Since PA already does some channel rearrangements it probably does make sense to export the audio device as 8ch device to PA and then have PA synthesize the extra null channels, however not expose them for volume control and suchlike.

Currently PA assumes that the channels of the PCM stream it sends to the device and the channels of the volume control it exposes for that are identical. I guess it is time to end that and disuitnighs both channel maps. In this case we might have more streams in the PCM stream than we want to show in the mixer UI. And for some devices the other way round is true as well (i.e. stereo stream with 2.1 volume control for LFE).

So I have now added another item to my todo list: to make that destinction between volume and PCM channel maps.

[timj]

I have an M-Audio Audiophile 24/96 (2 physical analogue inputs, 2 physical analogue outputs, 1 physical SPDIF in, 1 physical SPDIF out, but with 8 PCM channels) and I have to say that the above patch "pulseaudio-add-profile-sets-for-M_Audio-Audiophile-2496.patch" works perfectly for me (tested: analogue in/out, SPDIF out). Lennart, I understand your point in comment #23 re exposing "null" channels on the UI, but:

a) I'm not sure that exposing those channels is actually wrong. As far as I can tell, although they are not useful for a typical configuration, those channels are not useless (as I'll try to explain in a while)

b) even if it is, it sounds like this can't be resolved until the point in comment #29 (decoupling volume and PCM channel maps) is fixed. So would it be worth considering adding the profile set patch in the meantime?

These cards are certainly weird, but AFAICT the logic of having more PCM's than there are physical outputs is because the card is more like a mixing desk than a sound card: it can internally mix/patch multiple PCMs and acts as a layer of control which completely decouples both:

- the PCM channels from the digital mixer (N.B. digital mixer levels are also completely separate from the ADC/DAC volume controls)

- the physical inputs/outputs from anything else (via a patchbay) - you can assign each physical analogue/digital output to come from: PCM channels 1/2, digital mix L/R, or any of the physical inputs. (The patches seem to be exposed by ALSA as options called "H/W" and "H/W 1" for analogue out and "S/PDIF", "S/PDIF 1" for SPDIF out). By default, the analogue outputs (at least on my card) are usually set to PCM channels 1/2 (i.e. completely bypassing the card's internal multi-PCM digital mixer, and making it more like a "normal" 2-channel sound card where PCM1/2 are attached to physical L/R outputs - this seems like a sensible default).

It's a bit hard to explain, but the easiest way of controlling these is via "envy24control" (part of alsa-tools): http://images.google.co.uk/images?q=envy24control is probably the best way to see it. And I'm just about to attach an image of my envy24control patchbay (N.B. setting the S/PDIF output to "S/PDIF Out (L)" seems to do the same as setting the analogue output to "PCM Out 1", "S/PDIF Out (R)" == "PCM Out 2"). If I can post any more helpful screenshots let me know.

As far as I can tell (this is mostly from experimenting with envy24control), there is nothing actually special about PCM1/2 AFAICT, *except* that unlike the rest, you can patch the physical outputs to come directly from them as per the default configuration. (You can't patch the outputs to connect directly to e.g. PCM3/4, which seems to me to be an anomaly if the card is trying to emulate a "real" mixing desk, unless these PCM's really are "dead" and useless).

From my point of view as an owner of one of these cards, I accept that they work on a very different model to most cards and the only thing I really want PA to do is make sound go to (at least) PCM1/2 by default, which is what the modified mixer profile does. Exposing the other PCM's is not necessary for my personal scenario but probably actually a *good* thing in general for more esoteric configurations, assuming that PCM3..8 really do work. The only anomaly is that when using the patch above and all the "aux" channels are turned up (where aux0/1 = the card's PCM3/4), no sound seems to be actually sent to any PCM other than PCM1/2 (at least, the monitors in envy24control don't show anything, and patching the output to digital mix and unmuting PCM3/4..8 doesn't do anything). Unless (again) these PCM's really are dud. Technically speaking, it's also not quite right to call PCM1/2 "front left" and "front right", because if you switch the physical outputs to come from the digital mix then it seems like PCM1/2 are just like any other channel, and what actually goes to physical L/R output depends on how the channels are mixed.

The caveat with all the above is that actually all I use the card for is to provide straightforward 2-channel stereo output to analogue/SPDIF, so I haven't actually tried sending audio to the other PCMs. I'm not entirely clear how to test this - is there a magic ALSA device string? (I tried "aplay hw:3,1 ... " - my card is #3, but that didn't work)

[timj]

The patchbay settings in envy24control on an Audiophile 24/96

[tanuk]

A fix has been committed to alsa-lib that should enable stereo playback and capture out-of-the box for ICE1712 based cards:

http://git.alsa-project.org/?p=alsa-lib.git;a=commitdiff;h=d3906a93072171e5b5f4000d4a228af4eb8fa253

You may also be interested in the following Ubuntu bug, which led to the fix:

https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/178442

I'll resolve this as "elsewhere", since no changes are required to Pulseaudio.

[cyberpatrol]

Alsa is already able to do stereo playback and capture out-of-the box without a alsa.conf file. The problem is that those cards are not stereo sound cards but audio cards with two or more independent input and output channels which can be flexibly mixed. Pulseaudio can't handle this while alsa can, even if envy24control from alsa-tools is needed for mixing and setting the volume. Of course these independent channels can be set to just play and capture plain stereo, but they can do a lot more.

Setting such an alsa.conf which imitates a stereo sound card on those audio cards is just a dirty workaround for pulseaudio, but definitely not a fix for pulseaudio. This needs to be fixed in pulseaudio itself, not in alsa.

Btw., this alsa.conf hack probably removes some of the features of those cards.

[tanuk]

Replying to cyberpatrol:

Alsa is already able to do stereo playback and capture out-of-the box without a alsa.conf file. The problem is that those cards are not stereo sound cards but audio cards with two or more independent input and output channels which can be flexibly mixed. Pulseaudio can't handle this while alsa can, even if envy24control from alsa-tools is needed for mixing and setting the volume. Of course these independent channels can be set to just play and capture plain stereo, but they can do a lot more. Setting such an alsa.conf which imitates a stereo sound card on those audio cards is just a dirty workaround for pulseaudio, but definitely not a fix for pulseaudio. This needs to be fixed in pulseaudio itself, not in alsa. Btw., this alsa.conf hack probably removes some of the features of those cards.

No, it doesn't remove any features. The alsa configuration patch only affects what happens when an application tries to open the card using the device name "front" ("surround40" and "surround51" seem to be affected too in some way), which is defined to open a stereo stream. If you want to open the card in some other mode, then don't use the "front" device name.

If you're not happy with stereo playback and capture, please explain what exact configurations should be made available. Depending on what you want, the alsa configuration may need further tweaking. If the changes are not applicable to all ICE1712 cards, then I fear alsa's configuration system may not be flexible enough to implement that, but I don't know for sure. I'm not an expert on the alsa configuration system.