From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: Alsa handling of spdif bits (was Re: Questions to HDSP users) Date: Fri, 06 Feb 2004 12:53:37 +0100 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <402378E0.2060708@undata.org> Mime-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII Return-path: Received: from Cantor.suse.de (ns.suse.de [195.135.220.2]) by alsa.alsa-project.org (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id MAA29062 for ; Fri, 6 Feb 2004 12:59:41 +0100 In-Reply-To: <402378E0.2060708@undata.org> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: Thomas Charbonnel Cc: Jesse Chappell , ALSA development List-Id: alsa-devel@alsa-project.org 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. > > 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... > 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. Takashi ------------------------------------------------------- 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