[xine-devel] xine problem with newer alsa drivers (updated).

[VDR U. <use...@gm...>]

old alsa behavior:
setting >2 channels when >2 channels arent available results in
nothing.  no errors from alsa, the user only hears whatever channels
are available.

new alsa behavior:
setting channels limited to available channels reported by ELD/EDID
info. setting >2 channels when >2 channels arent available results in
error from alsa driver and xine reporting the following:
> ---------------------- (ERROR) ----------------------
> The audio device is unavailable. Please verify if another program
> already uses it.
>
> ['Audio device unavailable' '']
> ------------------ (END OF ERROR) -------------------

test case:
vdr+xine connected to receiver using hdmi audio/video. receiver
connected to tv using hdmi audio/video.  the pc is accessed only by
remote control to control vdr, or by SSH for everything else. no mouse
or keyboard connected.
with receiver on, eld reports 6 channels available.  with receiver
off, eld reports 2 channels available.
many people dont leave their receiver on 24/7, but rather only when
they need/want it so as not to waste power or have unwanted extra
noise.  for example, watching hd channels where only commercials are
surround while the show is stereo. this is common for shows that arent
recorded in surround.

with the new alsa behavior, if the receiver is off, xine loses audio
puts a popup window on the screen requiring the user to physically
address the issue. this is very inconvenient & annoying for users with
dedicated htpc as described above.

a better behavior more suitable for setups including receivers would
be to downmix surround audio to 2 channel stereo and re-attempt
opening the alsa driver with 2 channels.  if that fails, then report
the error.  this behavior could be optional in xine's config.  xine
should _not_ change the audio.output.speaker_arrangement setting so if
the user has set a surround speaker arrangement, xine will always
attempt that first, then fallback to downmixed 2 channel only if it
fails.  this will allow xine to continue along, not lose sound, and
not require the user login to the box to deal with the problem.

Will someone please help address this issue?

Best regards,
Derek