On Sat, 03.01.09 12:10, Colin Guthrie (gmane at colin.guthr.ie) wrote: > > is the same work-flow as on Windows). I read somewhere that a big > > showstopper for this is the detection of digital devices. Why not just > > adding a module parameter for that, because I guess that most users, > > including me, already have to add the digital output by hand, so e.g.: > > load-module module-alsa-sink device=iec958:0 capabilities=spdif,.. > > until hal/alsa gives some more information. > > Well you clearly know the score and what needs doing to make it kinda > work! I think you make good points about being able to dynamically > reconfigure sinks etc with different options. > > Lennart, do you have any plans in this area? I know that loading all the > sub-cards on a device can lock off the previous ones, but perhaps the > detection code can be tweaked to open+suspend, open+suspend each of them > so that they are nto all enabled at the same time. And perhaps some > auto-probing could then be done once all the devices are loaded to > detect whether the devices are mutually exclusive etc. Don't know if > this would be possible? If it is perhaps these mutually exclusive sinks > can be presented to the user as a single sink but with "sink options" of > some kind (e.g. 5.1 support, digial vs. analog vs. both, etc. etc.). > > Is this totally unreasonable? (A "suspend" of an ALSA device in PA is actually implemented by closing it) As pointed out I am planning to do autoprobing on startup about the configurations available and how they are exclusive to each other. It's ugly, but should be robust. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net ICQ# 11060553 http://0pointer.net/lennart/ GnuPG 0x1A015CC4
