Hi Greg,
Answer inline...
Greg Wright wrote:
(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?
I think newer sound cards allow detection of whether speakers are
plugged in, etc.
But I was only addressing misconfigured systems with incorrect ALSA
configuration files (for surround51 ALSA device).
It is hard to imaging that this can be auto-detected.
I think the problem is usually considered a Linux Distribution
configuration script bug.
(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?
PulseAudio is implementing this in its sound server. It is supposed to
be high-quality implementation.
So, I think there is a choice of Helix engine doing it, or letting
PulseAudio doing it.
It is something to investigate.
I think there are cool things that we can do with PulseAudio, but we
need to spend more time working on ALSA and PulseAudio device code.
[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?
I think the trend is doing it in software. PulseAudio is doing software
mixing in software only. I'm extrapolating it to software resampling,
but I don't know for sure if that is valid.
PulseAudio Software-only Mixing:
http://mail.gnome.org/archives/desktop-devel-list/2007-October/msg00136.html
Lennart Poettering <[email protected]> (one of the main PulseAudio
developers):
Hardware mixing is obsolete technology.
Mixing audio on the CPU is cheap and usually done with better and
more reliable quality.
HW mixing is dead technology.
It's out of fashion, made redundant by stuff that nowadays is
available in the CPU: MMX, SSE.
Using hw mixing imposes a greater burden on your USB, PCI busses,
might generate more IRQs.
The place to do mixing is nowadays the CPU -- it's one of the
reasons MMX, SSE where added to the CPU in the first place.
I *think* ALSA developer even said that there couldn't be hardware
resampling. This is what he said about ALSA dmix:
Takashi Iwai <[email protected]>:
The dmix cannot use the hardware resampling because the hardware
_is_ running on 48kHz.
I think sound card can only be configured to run with a sampling rate
(when it is initialized) in order to take that sampling rate. Other than
that, software has to perform resampling for the hardware.
That is what I know anyway.
Since we have tighter control over our engines re-sampling, then
perhaps that is the route we should take
:-)
Sound good.
--
Daniel Yek.
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
