[RFC] Zero-conf ALSA

[RFC] Zero-conf ALSA

[Lee Revell]

I would like to gather a list of the work remaining to be done to
achieve "zero-conf" ALSA.  With the increasing maturity of dmix and
softvol we are very close to this goal, and should be able to provide
basic soundcard functionality that users expect (mixing, volume control,
and OSS emulation) without requiring them to delve into cryptic config
files.

I propose to open a tracking bug in the ALSA BTS to gather all reports
of end users having to modify the config to get a working setup.  AFAICT
the remaining problems are:

  1. Devices which require dmix and/or softvol but are lacking the required 
     entries in the /usr/share/alsa/cards/ file.
  2. User-space OSS emulation over dmix requires period and the buffer sizes 
     to be set to powers of two.

#1 can only be solved by gathering user reports.

Can #2 be solved by having dmix prefer power of two period/buffer sizes
for the slave hw PCM by default?  AFAICT this should work unless an ALSA
app has opened the device first and set an incompatible buffer size.

Are there currently any other cases where an end user would have to
create a custom ALSA config to enable basic functionality?

Lee



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [Alsa-devel] [RFC] Zero-conf ALSA

[Takashi Iwai]

At Wed, 23 Nov 2005 23:03:44 -0500,
Lee Revell wrote:
> 
> I would like to gather a list of the work remaining to be done to
> achieve "zero-conf" ALSA.  With the increasing maturity of dmix and
> softvol we are very close to this goal, and should be able to provide
> basic soundcard functionality that users expect (mixing, volume control,
> and OSS emulation) without requiring them to delve into cryptic config
> files.
> 
> I propose to open a tracking bug in the ALSA BTS to gather all reports
> of end users having to modify the config to get a working setup.  AFAICT
> the remaining problems are:
> 
>   1. Devices which require dmix and/or softvol but are lacking the required 
>      entries in the /usr/share/alsa/cards/ file.
>   2. User-space OSS emulation over dmix requires period and the buffer sizes 
>      to be set to powers of two.
> 
> #1 can only be solved by gathering user reports.

Yes.

> Can #2 be solved by having dmix prefer power of two period/buffer sizes
> for the slave hw PCM by default?  AFAICT this should work unless an ALSA
> app has opened the device first and set an incompatible buffer size.

It's not so easy, unfortunately.  We'll need to fix to allow dmix the
arbitrary period/buffer sizes.  As long as the constraints of slave
PCM perido size exists, power-of-2 cannot be applied.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [Alsa-devel] [RFC] Zero-conf ALSA

[Lee Revell]

On Thu, 2005-11-24 at 11:28 +0100, Takashi Iwai wrote:
> > Can #2 be solved by having dmix prefer power of two period/buffer
> sizes
> > for the slave hw PCM by default?  AFAICT this should work unless an
> ALSA
> > app has opened the device first and set an incompatible buffer size.
> 
> It's not so easy, unfortunately.  We'll need to fix to allow dmix the
> arbitrary period/buffer sizes.  As long as the constraints of slave
> PCM perido size exists, power-of-2 cannot be applied. 

Is the power of 2 period size restriction imposed by OSS, or dmix?

Lee



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [Alsa-devel] [RFC] Zero-conf ALSA

[Takashi Iwai]

At Wed, 14 Dec 2005 17:27:01 -0500,
Lee Revell wrote:
> 
> On Thu, 2005-11-24 at 11:28 +0100, Takashi Iwai wrote:
> > > Can #2 be solved by having dmix prefer power of two period/buffer
> > sizes
> > > for the slave hw PCM by default?  AFAICT this should work unless an
> > ALSA
> > > app has opened the device first and set an incompatible buffer size.
> > 
> > It's not so easy, unfortunately.  We'll need to fix to allow dmix the
> > arbitrary period/buffer sizes.  As long as the constraints of slave
> > PCM perido size exists, power-of-2 cannot be applied. 
> 
> Is the power of 2 period size restriction imposed by OSS, or dmix?

It's OSS.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [RFC] Zero-conf ALSA

[Lee Revell]

On Thu, 2005-12-15 at 11:52 +0100, Takashi Iwai wrote:
> At Wed, 14 Dec 2005 17:27:01 -0500,
> Lee Revell wrote:
> > 
> > On Thu, 2005-11-24 at 11:28 +0100, Takashi Iwai wrote:
> > > > Can #2 be solved by having dmix prefer power of two period/buffer
> > > sizes
> > > > for the slave hw PCM by default?  AFAICT this should work unless an
> > > ALSA
> > > > app has opened the device first and set an incompatible buffer size.
> > > 
> > > It's not so easy, unfortunately.  We'll need to fix to allow dmix the
> > > arbitrary period/buffer sizes.  As long as the constraints of slave
> > > PCM perido size exists, power-of-2 cannot be applied. 
> > 
> > Is the power of 2 period size restriction imposed by OSS, or dmix?
> 
> It's OSS.

Then why can't the OSS emulation open the slave PCM with a power of 2
period size by default?  AFAICT this would only fail if someone else has
already opened the slave PCM with a non power of 2 period/buffer.

Lee



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [RFC] Zero-conf ALSA

[Takashi Iwai]

At Thu, 15 Dec 2005 13:06:02 -0500,
Lee Revell wrote:
> 
> On Thu, 2005-12-15 at 11:52 +0100, Takashi Iwai wrote:
> > At Wed, 14 Dec 2005 17:27:01 -0500,
> > Lee Revell wrote:
> > > 
> > > On Thu, 2005-11-24 at 11:28 +0100, Takashi Iwai wrote:
> > > > > Can #2 be solved by having dmix prefer power of two period/buffer
> > > > sizes
> > > > > for the slave hw PCM by default?  AFAICT this should work unless an
> > > > ALSA
> > > > > app has opened the device first and set an incompatible buffer size.
> > > > 
> > > > It's not so easy, unfortunately.  We'll need to fix to allow dmix the
> > > > arbitrary period/buffer sizes.  As long as the constraints of slave
> > > > PCM perido size exists, power-of-2 cannot be applied. 
> > > 
> > > Is the power of 2 period size restriction imposed by OSS, or dmix?
> > 
> > It's OSS.
> 
> Then why can't the OSS emulation open the slave PCM with a power of 2
> period size by default?  AFAICT this would only fail if someone else has
> already opened the slave PCM with a non power of 2 period/buffer.

Hint: different sample rates.

dmix is running on a fixed sample rate, and if you open an OSS device
with a different sample rate, you need to convert it.  The period
size/buffer is based on the original sample rate, so...


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [RFC] Zero-conf ALSA

[Lee Revell]

On Wed, 2005-11-23 at 23:03 -0500, Lee Revell wrote:
> I would like to gather a list of the work remaining to be done to
> achieve "zero-conf" ALSA.  With the increasing maturity of dmix and
> softvol we are very close to this goal, and should be able to provide
> basic soundcard functionality that users expect (mixing, volume control,
> and OSS emulation) without requiring them to delve into cryptic config
> files.
> 
> I propose to open a tracking bug in the ALSA BTS to gather all reports
> of end users having to modify the config to get a working setup.  AFAICT
> the remaining problems are:
> 
>   1. Devices which require dmix and/or softvol but are lacking the required 
>      entries in the /usr/share/alsa/cards/ file.
>   2. User-space OSS emulation over dmix requires period and the buffer sizes 
>      to be set to powers of two.

Another thing that's been pointed out is 5.1 upmixing of stereo sources.
How much work would it be to have this work OOTB for devices that can't
do it in hardware?

Lee



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click

Re: [RFC] Zero-conf ALSA

[Peter Kirk]

[-- Attachment #1: Type: text/plain, Size: 716 bytes --]

On Thursday 24 November 2005 05:03, Lee Revell wrote:
> I would like to gather a list of the work remaining to be done to
> achieve "zero-conf" ALSA.  With the increasing maturity of dmix and
> softvol we are very close to this goal, and should be able to provide
> basic soundcard functionality that users expect (mixing, volume control,
> and OSS emulation) without requiring them to delve into cryptic config
> files.
Hi there,

this "zero-conf" ALSA sounds very nice, but I think you forgot one aspect. 
What about adding dsnoop to that list, and theirby allowing users to also use 
their capture device multiple times?

Peter
-- 
To do two things at once is to do neither.
		-- Publilius Syrus

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]