Re: Alsa mix in HW

Re: Alsa mix in HW

[Raymond]

snd_pcm_hardware_t of the sound cards will need to support

1) Hardware Mixing ( spatializing mono audio stream into 2, 4, 5.1, .. 
speakers

.channels_min  = 1
.formats =  SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_U8

2) Doppler Effect ( Frequency shift by pitch )

.rates = SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000 or 
SNDRV_PCM_RATE_8000_44100

3) Recording API ( full duplex )

4) Mono/Stero Hint ( Playing stereo background music )

.channels_max >= 2

Do anyone have a list of the sound cards ( alsa driver ) which support 
the above features ?


Dino Puller wrote:

> 
> Hi all,
>    here http://dino.e4a.it/openal-alsa you can find an implementation of 
> OpenAL library that can mix sources in HW. It's based on C.J.Purnell 
> openal-alsa-emu10k1 but in this one i've replaced all code relative to 
> emu10k1 processor, with a more compatible one, so now it's should works 
> with every sound card that supports multiple sub streams. It's not based 
> on OpenAL official tree because it's play too much with conversions to a 
> canonical format of samples witch slow down any trial to mix in 
> hardware. Don't expect too much it's only a first release but it's seems 
> to works.
> 
> 
> bye,
>    Dino Puller



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Alsa mix in HW

[Lee Revell]

On Wed, 2005-08-17 at 20:42 +0800, Raymond wrote:
> Do anyone have a list of the sound cards ( alsa driver ) which support
> the above features ? 

Vortex and emu10k1/2 at least...

Lee



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Alsa mix in HW

[Takashi Iwai]

At Wed, 17 Aug 2005 12:42:26 -0400,
Lee Revell wrote:
> 
> On Wed, 2005-08-17 at 20:42 +0800, Raymond wrote:
> > Do anyone have a list of the sound cards ( alsa driver ) which support
> > the above features ? 
> 
> Vortex and emu10k1/2 at least...

You can count ymfpci and trident, too. 


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Alsa mix in HW

[Manuel Jander]

On Wed, 2005-08-17 at 19:25 +0200, Takashi Iwai wrote:
> At Wed, 17 Aug 2005 12:42:26 -0400,
> Lee Revell wrote:
> > 
> > On Wed, 2005-08-17 at 20:42 +0800, Raymond wrote:
> > > Do anyone have a list of the sound cards ( alsa driver ) which support
> > > the above features ? 
> > 
> > Vortex and emu10k1/2 at least...
> 
> You can count ymfpci and trident, too. 

ESS Maestro. The 3D HRTF pipelines does not seem to be clear how they
can be used, but AFAIK the hardware mixing and pitch programming should
be possible.

Best Regards,
Manuel




-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Alsa mix in HW

[Manuel Jander]

Hi,

> Refer to Section 3.4 Attenuation by Distance.
> 
> Samples usually use the entire dynamic range of the chosen
> format/encoding, independent of their real world intensity.
> ...
> The Application will then have to adjust source gain accordingly to
> account for relative differences.
> 
> Source gain is attenuated by distance.
> 
> 
> Do you know how to provide attenuation when using the hardware mixer of
> au88x0 ?  ( -48dB to +6dB )
> 
> #define MIX_DEFIGAIN 0x08
> #define MIX_DEFOGAIN 0x08       /* 0x8->6dB  (6dB = x4) 16 to 18 bit
> conversion? */
 
As AFAIK, many time ago, while translating the assembler jungle into
C, I found a function that looked like translating gain factors into
dB. The relation was a factor difference of 8 being equivalent to 6
dB. So in theory, on the aureal vortex we can change the gain of each
hardware channel knowing the relative gain in dB. Absolute gain can
never be known for sure.

The 16 hardware HRTF pipes have additional gains as part of the
processing pipelines, but they are used mainly for Interaural Level
Differences. Well, fiddling with the equalizer and Crosstalk canceller
the gain can be changed too, so there are plenty of posibilities to
change final mix gains.
 
> #define VORTEX_MIX_INVOL_B 0x20000      /* Input volume current */
> #define VORTEX_MIX_VOL_B 0x20800        /* Output Volume current */
> #define VORTEX_MIX_INVOL_A 0x21000      /* Input Volume target */
> #define VORTEX_MIX_VOL_A 0x21800        /* Output Volume target */

There are current and target settings for almost all hardware
parameters, which are intended to do automatic sliding / fading of
values. But the original drivers never did made use of this feature. I
guess because its just hard to do that, because OpenAL or whatever lib
would require to describe events of the future. In the end its easier
and less complex to just update the hardware context multiple times.
Looks like a neat idea that was thrown away afterwards.

Best Regards
Manuel


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Alsa mix in HW

[Raymond]

Manuel Jander wrote:
> On Wed, 2005-08-17 at 19:25 +0200, Takashi Iwai wrote:
>
>>At Wed, 17 Aug 2005 12:42:26 -0400,
>>Lee Revell wrote:
>>
>>>On Wed, 2005-08-17 at 20:42 +0800, Raymond wrote:
>>>
>>>>Do anyone have a list of the sound cards ( alsa driver ) which
>>>>support the above features ?
>>>
>>>Vortex and emu10k1/2 at least...
>>
>>You can count ymfpci and trident, too.
>
>
> ESS Maestro. The 3D HRTF pipelines does not seem to be clear how they
> can be used, but AFAIK the hardware mixing and pitch programming
> should be possible.
>

Since ALSA support multiple sound cards, it is possible to use onboard
sound chip as capturing device.

Is it feasible to use one or more sound cards for playback ? (e.g. 
on-board sound chip with dmix is capable of playing stereo background 
music, or you have two sound cards which support hardware mixing)


Refer to 4.3.2 Source Attributes

Get/Set Offset

AL_SEC_OFFSET - the playback position expressed in seconds.
...
This value is based on byte position, so a pitch-shifted source will
have an exaggerated playback speed. For example you can be 0.500 seconds
into a buffer having taken only 0.250 seconds to get there if the pitch
is set to 2.0

AL_SAMPLE_OFFSET - the playback position  expressed in samples

AL_BYTE_OFFSET - the playback position, expressed in bytes.


Do "SNDRV_PCM_RATE_CONTINUOUS" in snd_hardware_t mean that sample rate 
can be any integer between .rate_min and .rate_max ?

Since changing sample rate while playing is not offically supported by
ALSA. The audio are usually play in LOOP, is it feasible to change the
sample rate at the start of each loop if doppler effect is required ?


Refer to src/alc_device.c

#define _ALC_DEF_FREQ 44100
#define _ALC_NUM_PERIODS 2
#define _ALC_BUFFER_SIZE 4096


	if (snd_pcm_hw_params_set_channels(src->handle, hw_params, 2))
		return ALC_FALSE;

	src->freq = dev->freq;
	if (snd_pcm_hw_params_set_rate_near(src->handle, hw_params, &src->freq, 0))
		return ALC_FALSE;

	src->periods = _ALC_NUM_PERIODS;
	if (snd_pcm_hw_params_set_periods_near(src->handle, hw_params, 
&src->periods,0))
		return ALC_FALSE;


	size = _ALC_BUFFER_SIZE;
	if (snd_pcm_hw_params_set_buffer_size_near(src->handle, hw_params, &size))
		return ALC_FALSE;


1) most of the audio are mono except those stereo backgroud music.
2) is there any special reason to use _near() function to set rate, 
period_size and buffer_size in that order ?






-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Alsa mix in HW

[Takashi Iwai]

At Sat, 20 Aug 2005 16:30:31 +0800,
Raymond wrote:
> 
> Manuel Jander wrote:
> > On Wed, 2005-08-17 at 19:25 +0200, Takashi Iwai wrote:
> >
> >>At Wed, 17 Aug 2005 12:42:26 -0400,
> >>Lee Revell wrote:
> >>
> >>>On Wed, 2005-08-17 at 20:42 +0800, Raymond wrote:
> >>>
> >>>>Do anyone have a list of the sound cards ( alsa driver ) which
> >>>>support the above features ?
> >>>
> >>>Vortex and emu10k1/2 at least...
> >>
> >>You can count ymfpci and trident, too.
> >
> >
> > ESS Maestro. The 3D HRTF pipelines does not seem to be clear how they
> > can be used, but AFAIK the hardware mixing and pitch programming
> > should be possible.
> >
> 
> Since ALSA support multiple sound cards, it is possible to use onboard
> sound chip as capturing device.
> 
> Is it feasible to use one or more sound cards for playback ? (e.g. 
> on-board sound chip with dmix is capable of playing stereo background 
> music, or you have two sound cards which support hardware mixing)

It's feasible via alsa-lib multi plugin.

> Refer to 4.3.2 Source Attributes
> 
> Get/Set Offset
> 
> AL_SEC_OFFSET - the playback position expressed in seconds.
> ...
> This value is based on byte position, so a pitch-shifted source will
> have an exaggerated playback speed. For example you can be 0.500 seconds
> into a buffer having taken only 0.250 seconds to get there if the pitch
> is set to 2.0
> 
> AL_SAMPLE_OFFSET - the playback position  expressed in samples
> 
> AL_BYTE_OFFSET - the playback position, expressed in bytes.
> 
> 
> Do "SNDRV_PCM_RATE_CONTINUOUS" in snd_hardware_t mean that sample rate 
> can be any integer between .rate_min and .rate_max ?

Basically, yes.  A driver might add another restriction but in such a
case it should use RATE_KNOT instead.

> Since changing sample rate while playing is not offically supported by
> ALSA. The audio are usually play in LOOP, is it feasible to change the
> sample rate at the start of each loop if doppler effect is required ?

Changing the rate during the DMA is running is not officially
supported.  This reads: you have to stop the stream once to change the
parameter.  This isn't what you want, I guess.


> Refer to src/alc_device.c
> 
> #define _ALC_DEF_FREQ 44100
> #define _ALC_NUM_PERIODS 2
> #define _ALC_BUFFER_SIZE 4096
> 
> 
> 	if (snd_pcm_hw_params_set_channels(src->handle, hw_params, 2))
> 		return ALC_FALSE;
> 
> 	src->freq = dev->freq;
> 	if (snd_pcm_hw_params_set_rate_near(src->handle, hw_params, &src->freq, 0))
> 		return ALC_FALSE;
> 
> 	src->periods = _ALC_NUM_PERIODS;
> 	if (snd_pcm_hw_params_set_periods_near(src->handle, hw_params, 
> &src->periods,0))
> 		return ALC_FALSE;
> 
> 
> 	size = _ALC_BUFFER_SIZE;
> 	if (snd_pcm_hw_params_set_buffer_size_near(src->handle, hw_params, &size))
> 		return ALC_FALSE;
> 
> 
> 1) most of the audio are mono except those stereo backgroud music.
> 2) is there any special reason to use _near() function to set rate, 
> period_size and buffer_size in that order ?

The requested rate isn't supported always.

The order of hw_params calls may influence the resultant parameters.
Especially, the parameters for period and buffer sizes are very
sensitive.

Usually, the order of period_size -> buffer_size is more stable than
buffer_size -> period_size.


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Alsa mix in HW

[Raymond]

Takashi Iwai wrote:
> At Sat, 20 Aug 2005 16:30:31 +0800,
> Raymond wrote:
> 
>>
>>
>>Do "SNDRV_PCM_RATE_CONTINUOUS" in snd_hardware_t mean that sample rate 
>>can be any integer between .rate_min and .rate_max ?
> 
> 
> Basically, yes.  A driver might add another restriction but in such a
> case it should use RATE_KNOT instead.
> 

Is there any quick way to check the device "hw:x,x" support
"SNDRV_PCM_RATE_CONTINUOUS" without running
snd_pcm_hw_param_test_rate() (rate_max-rate_min+1) times ?

Are the following result normal when using the following fuctions on 
device "plughw:x,x" ?

rate_min=4000 for snd_pcm_hw_params_get_rate_min()
rate_max=-1   for snd_pcm_hw_params_get_rate_max()










-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Re: Alsa mix in HW

[Takashi Iwai]

At Tue, 23 Aug 2005 23:45:09 +0800,
Raymond wrote:
> 
> Takashi Iwai wrote:
> > At Sat, 20 Aug 2005 16:30:31 +0800,
> > Raymond wrote:
> > 
> >>
> >>
> >>Do "SNDRV_PCM_RATE_CONTINUOUS" in snd_hardware_t mean that sample rate 
> >>can be any integer between .rate_min and .rate_max ?
> > 
> > 
> > Basically, yes.  A driver might add another restriction but in such a
> > case it should use RATE_KNOT instead.
> > 
> 
> Is there any quick way to check the device "hw:x,x" support
> "SNDRV_PCM_RATE_CONTINUOUS" without running
> snd_pcm_hw_param_test_rate() (rate_max-rate_min+1) times ?

No specific method, so far.
As a practical test, you can try some strage rates instead of all
values.

> Are the following result normal when using the following fuctions on 
> device "plughw:x,x" ?
> 
> rate_min=4000 for snd_pcm_hw_params_get_rate_min()
> rate_max=-1   for snd_pcm_hw_params_get_rate_max()

Judging the plug layer from such values is not recommended at all.
If you want to skip the software SRC, set 0 to
snd_pcm_hw_params_set_rate_resample().


Takashi


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

Re: Alsa mix in HW

[Raymond]

Dino,

Do your sound cards has devices (snd_hardware_t) support the following
features ?

1) Hardware mixing (no. of subdevices > 1 ??? )
2) Panning mono to 2 or more speakers (.channels_min = 1 and pcm 
volume/panning control for each subdevice)
3) Playback 8/16 bits mono/stereo audio (.format )
3) Doppler Effect (.rate = SNDRV_PCM_RATE_CONTINUOUS )
4) Recording API (capture 8/16 bits mono/stereo audio)
5) Background music (.channels_max >= 2 )


Valid Formats are AL_FORMAT_MONO8, AL_FORMAT_MONO16, AL_FORMAT_STEREO8
and AL_FORMAT_STEREO16.

Refer to alsa-lib/include/pcm.h

	/** Signed 8 bit */
	SND_PCM_FORMAT_S8 = 0,
	/** Unsigned 8 bit */
	SND_PCM_FORMAT_U8,
	/** Signed 16 bit Little Endian */
	SND_PCM_FORMAT_S16_LE,
	/** Signed 16 bit Big Endian */
	SND_PCM_FORMAT_S16_BE,
	/** Unsigned 16 bit Little Endian */
	SND_PCM_FORMAT_U16_LE,
	/** Unsigned 16 bit Big Endian */
	SND_PCM_FORMAT_U16_BE,

Is the audio data stored in the alBuffer signed or unsigned ?


Takashi Iwai wrote:
> At Sat, 20 Aug 2005 16:30:31 +0800,
> Raymond wrote:
> 
>>Manuel Jander wrote:
>>
>>>On Wed, 2005-08-17 at 19:25 +0200, Takashi Iwai wrote:
>>>
>>>
>>>>At Wed, 17 Aug 2005 12:42:26 -0400,
>>>>Lee Revell wrote:
>>>>
>>>>
>>>>>On Wed, 2005-08-17 at 20:42 +0800, Raymond wrote:
>>>>>
>>>>>
>>>>>>Do anyone have a list of the sound cards ( alsa driver ) which
>>>>>>support the above features ?
>>>>>
>>>>>Vortex and emu10k1/2 at least...
>>>>
>>>>You can count ymfpci and trident, too.
>>>
>>>
>>>ESS Maestro. The 3D HRTF pipelines does not seem to be clear how they
>>>can be used, but AFAIK the hardware mixing and pitch programming
>>>should be possible.
>>>
>>
>>Since ALSA support multiple sound cards, it is possible to use onboard
>>sound chip as capturing device.
>>
>>Is it feasible to use one or more sound cards for playback ? (e.g. 
>>on-board sound chip with dmix is capable of playing stereo background 
>>music, or you have two sound cards which support hardware mixing)
> 
> 
> It's feasible via alsa-lib multi plugin.
> 
> 
>>Refer to 4.3.2 Source Attributes
>>
>>Get/Set Offset
>>
>>AL_SEC_OFFSET - the playback position expressed in seconds.
>>...
>>This value is based on byte position, so a pitch-shifted source will
>>have an exaggerated playback speed. For example you can be 0.500 seconds
>>into a buffer having taken only 0.250 seconds to get there if the pitch
>>is set to 2.0
>>
>>AL_SAMPLE_OFFSET - the playback position  expressed in samples
>>
>>AL_BYTE_OFFSET - the playback position, expressed in bytes.
>>
>>
>>Do "SNDRV_PCM_RATE_CONTINUOUS" in snd_hardware_t mean that sample rate 
>>can be any integer between .rate_min and .rate_max ?
> 
> 
> Basically, yes.  A driver might add another restriction but in such a
> case it should use RATE_KNOT instead.
> 
> 
>>Since changing sample rate while playing is not offically supported by
>>ALSA. The audio are usually play in LOOP, is it feasible to change the
>>sample rate at the start of each loop if doppler effect is required ?
> 
> 
> Changing the rate during the DMA is running is not officially
> supported.  This reads: you have to stop the stream once to change the
> parameter.  This isn't what you want, I guess.
> 

Any significant change of frequency shift which can be detected by the 
human ears. ( e.g. listener/source accelerate/decelerate or change 
direction )

Refer to 3.5.2 Velocity dependent Doppler Effect.

The doppler effect will depends on
1) Source velocity
2) Listener velocity
3) AL_SPEED_OF_SOUND (speed of the sound in medium, default value 343.3)
4) AL_DOPPLER_FACTOR (zero = disable doppler effect, default 1.0)


Any sound card (alsa-driver) can produce doppler effect using special
device/synth device other than changing sample rate ?

> 
> 
>>Refer to src/alc_device.c
>>
>>#define _ALC_DEF_FREQ 44100
>>#define _ALC_NUM_PERIODS 2
>>#define _ALC_BUFFER_SIZE 4096
>>
>>
>>	if (snd_pcm_hw_params_set_channels(src->handle, hw_params, 2))
>>		return ALC_FALSE;
>>

Refer to 5.3.4 Specifying Buffer Content

Buffer contains audio with more than one channels will be played with 3D
spatialization features - these formats are normally used for background
music.

This means alcOpenDevice will base on the channels of the audio to find
the suitable device from the available sound cards.

The structure AL_source should contain format/channels of the audio and
device/subdevice or "device name" to allow sound card use different
devices to handle mono stream for 3D spatialization and the background 
music.

There is no existing ALSA-LIB functions which can set the pcm volume 
control of the subdevice to the speakers for all sound cards.

Each device of different sound cards may have different kcontrols to 
change left/right volume , front/rear volume, reverb, delay, ...

What is the best/fast method to identify the devices of different sound 
cards in order to call the hardware depdendent routine ?

const char *snd_pcm_info_get_id(const snd_pcm_info_t *obj);
const char *snd_pcm_info_get_name(const snd_pcm_info_t *obj);
const char *snd_pcm_info_get_subdevice_name(const snd_pcm_info_t *obj);


>>	src->freq = dev->freq;
>>	if (snd_pcm_hw_params_set_rate_near(src->handle, hw_params, &src->freq, 0))
>>		return ALC_FALSE;
>>
>>	src->periods = _ALC_NUM_PERIODS;
>>	if (snd_pcm_hw_params_set_periods_near(src->handle, hw_params, 
>>&src->periods,0))
>>		return ALC_FALSE;
>>
>>
>>	size = _ALC_BUFFER_SIZE;
>>	if (snd_pcm_hw_params_set_buffer_size_near(src->handle, hw_params, &size))
>>		return ALC_FALSE;
>>
>>
>>1) most of the audio are mono except those stereo backgroud music.
>>2) is there any special reason to use _near() function to set rate, 
>>period_size and buffer_size in that order ?
> 
> 
> The requested rate isn't supported always.

These should not be a problem if the device support 
SNDRV_PCM_RATE_CONTINUOUS.

Is there any software SRC ALSA plugin ?

> 
> The order of hw_params calls may influence the resultant parameters.
> Especially, the parameters for period and buffer sizes are very
> sensitive.
> 
> Usually, the order of period_size -> buffer_size is more stable than
> buffer_size -> period_size.
> 

Do any devices of the sound cards in the above list require a special 
period_size/buffer_size to produce special effect ?

>>Are the following result normal when using the following fuctions on
>>device "plughw:x,x" ?
>>
>>rate_min=4000 for snd_pcm_hw_params_get_rate_min()
>>rate_max=-1   for snd_pcm_hw_params_get_rate_max()
>
>
> Judging the plug layer from such values is not recommended at all.
> If you want to skip the software SRC, set 0 to
> snd_pcm_hw_params_set_rate_resample().
>

The OpenAL 1.1 specification do not have restriction on frequency and
format when capturing audio.

Do ALSA support rate_resample/reformat when using "plughw:0,0" to 
capture 8/16 bits mono/stereo audio ?






-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf