[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-audio-dev
Subject:    [Audio-dev] Re: (347Atlas only.) Merge Software Volume Control,
From:       Daniel Yek <dyek () real ! com>
Date:       2009-01-29 19:53:26
Message-ID: 49820936.1010300 () real ! com
[Download RAW message or body]

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 <mzerqung@0pointer.de> (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 <tiwai@suse.de>:

    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
Audio-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
[prev in list] [next in list] [prev in thread] [next in thread]