At Fri, 06 Feb 2004 12:22:08 +0100, Thomas Charbonnel wrote:
(BTW Takashi iecset -h says 'audio on' is non-audio and 'audio off' is audio but it seems to be the other way round, unless the hdsp driver is wrong here...)
yep, fixed now on CVS :)
The problem I see and I dislike with this is that iec bits are associated with playback. This is probably fine with most devices, but not with hardware that can do hardware routing, where you may want to route signal through the S/PDIF out with a certain bit combination - no playback is involved here. I believe a generic iec bits handling interface is a good thing, but is should not be affected by the card's status. Any comment on this Takashi ?
well, in that case, the put callback of "IEC958 Playback Default" should change the corresponding register value immediately, too.
Ok, but it seems this can't be done with iecset, so I'm back with my question concerning amixer : all the 'value' fields of IEC ctls show a question mark. Is this a problem with the driver ? If not what would be the syntax to access those ctls ?
An aside: this is also complicated because to open the device, the channels item in the slave.pcm section must match the iobox in use (multiface or digiface) which have differing channel counts. So when we do get this working, it will be a problem to handle both cases in a conf file.
Not to mention that there is also a shift in the S/PDIF channels position when the card changes speed mode... Can the current configuration mechanism handle this properly ?
when the channel position changes dynamically according to the certain state, it'd be difficult with the current config without addition...
In case you plan to implement those additions, let me know if there is anything to adapt on the driver side.
Similarly we would need different .conf files for the different hdsp cards, but seeing Takashi's patch, it seems .conf files are associated with a card using the generic driver name (here 'H-DSP'). Is there a way to affect a .conf file to a specific submodel ?
the easiest way is to change the driver name per model. for example, emu10k1 driver provides "EMU10k1", "Audigy" and "Audigy2" according to the model.
Ok, this will be part of the driver update I'm working on ATM.
Thomas
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel