(2)
Renamed DisableMultiChannelPlayback (old)
to PlaybackMultiChannelAsStereo (new).
gwright suggested to use "DisableMultiChannelPlayback" Preference here:
http://lists.helixcommunity.org/pipermail/audio-dev/2006-October/000773.html
dyek:
// Add "DisableSurroundSoundPlayback" into the Preference.
gwright:
I think that "DisableMultiChannelPlayback" might be a clearer name.
I found both "DisableSurroundSoundPlayback" and
"DisableMultiChannelPlayback" were not obvious in its meaning.
So, I decided to take the opportunity to rename the Preference to
"PlaybackMultiChannelAsStereo", which, hopefully, is more understandable.
Setting the Preferences would cause surround sound channels to be
played from the front stereo speakers.
It is especially useful if the user's system speakers are not configured
properly to play surround sound content successfully.
Can we auto-detect such a configuration?
(3)
ALSA now always configures the sound card to 48000Hz.
So, Helix's ALSA audio device _CheckFormat() code now forces Helix client
to use 48000Hz.
However, a user could change the "AlsaVaryingSampleRate" preference entry
in the following file like this:
~/.config/real/realplayerrc or ~/.helix/HelixSDK_10_0:
AlsaVaryingSampleRate=1
With this, the previous player behavior is preserved to use whatever
sample rate ALSA plug layer is accepting. ALSA's plug layer would
then resample to 48000Hz before sending it to the device.
We should give this some thought, it basically comes down to deciding
where we want the re-sampling to occur (for all non-48Khz content). Do
we want the engine to do it or do we want the audio device to do it?
[I assume that if we ask ALSA to open up at 22Khz it will say 'OK' but
re-sample to 48Khz anyway.]
If ALSA will take our, for example, 22Khz content, will it resample in
hardware or some software layer? Can we tell? Since we have tighter
control over our engines re-sampling, then perhaps that is the route
we should take since CPU usage is not too much of a concern anymore
on desktops (with regard to audio-only playback).
Looks good.
--greg.
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
