smart and automatic use of dmix and dsnoop - feature suggestion.

smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi guys,

In the last few days I have been reading a lot about how to mix streams into 
one in order to allow *weak* soundcards to play multiple streams, even though 
they cant do that in hardware. This seems to be doable with dmix. Also, I 
have thought about the situation where the capture devices are used up, for 
this I found the plugin "dsnoop". 
After thinking a bit about the situation I thought the following would be a 
great idea (a feature suggestion to alsa):

Alsa knows howmany playback and howmany capture devices it has, and it also 
knows howmany times they can be opened. So, the result are two numbers:
The amount of streams that can be played back in hardware, AND
The amount of times an application can open a capture stream.

So, these are two numbers - and basicly all is fine as long as you dont want 
to excede them, but if you do, you need to use dmix or dsnoop. Why not use 
dmix and dsnoop automaticly when necessary ? Wouldnt it be possible to have 
every application play through something like a "smartdmix", that would just 
pass on the sound-streams to real-world devices, as long as there are still 
playback devices that can handle annother stream...once the user opens a 
playback stream while there is no *free*slot* for it, the "smartdmix" would 
start mixing this stream with one of the already existing streams, making it 
possible to play back although the hardware wouldnt have supported the extra 
stream.
Same idea with the capture part...as long as there are still capture devices a 
utility called "smartdsnoop" would just pass on the capture stream directly 
from the existing capture device, and only once the first application is 
opened that claims to need to capture and for which there is no free capture 
device, smartdsnoop would split one capture stream into two - and so be able 
to serve this new application.

After all this babble, here is what I expect from the above:
- - Near zero overhead as long as the system uses the soundcard in the limits 
the soundcard provides.
- - Support for any amount of playback and capture streams, no matter on what 
soundcard (provided of course the soundcard has at least one playback and one 
capture device :D).
- - Near zero configuration/tuning work needed to be done by the user, all done 
by smartdmix and smartdsnoop.
- - Low cpu and latency misuse  - since the *mixing* or *spliting* capabilities 
are only activated when needed, and deactivated when not used anymore.

Hope to hear your opinions on this,
Peter
- -- 
Take what you can use and let the rest go by.
		-- Ken Kesey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/tDNJg2ieGvTmHiURAl0XAJ9iEIqiEQAfhGElsAh8ddNtBu9YKQCbB7qF
jx5IU70naqNZrMbYtejShFY=
=dFm/
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Paul Davis]

>So, these are two numbers - and basicly all is fine as long as you dont wan=
>t=20
>to excede them, but if you do, you need to use dmix or dsnoop. Why not use=
>=20
>dmix and dsnoop automaticly when necessary ? Wouldnt it be possible to have=

because it would be catastrophic, or, well, at least very bad, for
applications that want to "sit close to the metal".

this is a user-space configuration issue, not something that alsa-lib
should do by default. if the user (or the distributor) defines "dmix"
to be the default device type, then every conformant ALSA application
will do the right thing. apps like JACK that want to "site close to
the metal" will still use "hw:N" unless you tell it otherwise, but
consumer apps will use "default" (that's what i mean by conformant)
and get dmix behaviour.

--p



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Freitag, 14. November 2003 13:21 schrieb Paul Davis:
> >So, these are two numbers - and basicly all is fine as long as you dont
> > wan= t=20
> >to excede them, but if you do, you need to use dmix or dsnoop. Why not
> > use= =20
> >dmix and dsnoop automaticly when necessary ? Wouldnt it be possible to
> > have=
>
> because it would be catastrophic, or, well, at least very bad, for
> applications that want to "sit close to the metal".
>
> this is a user-space configuration issue, not something that alsa-lib
> should do by default. if the user (or the distributor) defines "dmix"
> to be the default device type, then every conformant ALSA application
> will do the right thing. apps like JACK that want to "site close to
> the metal" will still use "hw:N" unless you tell it otherwise, but
> consumer apps will use "default" (that's what i mean by conformant)
> and get dmix behaviour.
Hmm,

are you telling me that normal applications will already automaticly use
dmix ? Its a pitty my soundcard (SB Live!) can play so many streams in
hardware at once, so I dont realy know if alsa is doing dmixing *on*the*fly*.
But I did *think* that if you had a cheepo laptop, you couldnt open 5 xmms
and 5 xines and start playing back with all of them - I could be wrong of
course. The thing Im quite certain of, is that there is no dmix jumping in if
you try to run 2 playback oss apps through the oss emulation layer of alsa -
this will give you trouble if your soundcard cant play two streams in
hardware.
Then there still would be the point with dsnoop - I _know_ it doesnt work on
my soundcard to open two instances of TeamSpeak (voice communication -> full
duplex) - and be able to talk and hear on both...this is because the capture
device is taken.
Is there anything being thought about of something like the automagic
dsnooping I was talking about ? It realy would be nice to be able to use
multiple applications of teamspeak on *normal* soundcards like mine...

Peter
- --
If at first you don't succeed, destroy all evidence that you tried.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/tNIVg2ieGvTmHiURAmeBAKCJvLpZaXJjzkPuseruoYAOoWQfFgCgg8PD
RyyFJAeQdCAqv4PsPYoQ9qo=
=i5nu
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Takashi Iwai]

At Fri, 14 Nov 2003 14:01:09 +0100,
Peter Kirk wrote:
> 
> WARNING: Unsanitized content follows.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Freitag, 14. November 2003 13:21 schrieb Paul Davis:
> > >So, these are two numbers - and basicly all is fine as long as you dont
> > > wan= t=20
> > >to excede them, but if you do, you need to use dmix or dsnoop. Why not
> > > use= =20
> > >dmix and dsnoop automaticly when necessary ? Wouldnt it be possible to
> > > have=
> >
> > because it would be catastrophic, or, well, at least very bad, for
> > applications that want to "sit close to the metal".
> >
> > this is a user-space configuration issue, not something that alsa-lib
> > should do by default. if the user (or the distributor) defines "dmix"
> > to be the default device type, then every conformant ALSA application
> > will do the right thing. apps like JACK that want to "site close to
> > the metal" will still use "hw:N" unless you tell it otherwise, but
> > consumer apps will use "default" (that's what i mean by conformant)
> > and get dmix behaviour.
> Hmm,
> 
> are you telling me that normal applications will already automaticly use
> dmix ? Its a pitty my soundcard (SB Live!) can play so many streams in
> hardware at once, so I dont realy know if alsa is doing dmixing *on*the*fly*.
> But I did *think* that if you had a cheepo laptop, you couldnt open 5 xmms
> and 5 xines and start playing back with all of them - I could be wrong of
> course. The thing Im quite certain of, is that there is no dmix jumping in if
> you try to run 2 playback oss apps through the oss emulation layer of alsa -
> this will give you trouble if your soundcard cant play two streams in
> hardware.
> Then there still would be the point with dsnoop - I _know_ it doesnt work on
> my soundcard to open two instances of TeamSpeak (voice communication -> full
> duplex) - and be able to talk and hear on both...this is because the capture
> device is taken.
> Is there anything being thought about of something like the automagic
> dsnooping I was talking about ? It realy would be nice to be able to use
> multiple applications of teamspeak on *normal* soundcards like mine...

you can override the "default" pcm to use dmix/dsnoop plugin by
defining it with '!' prefix in ~/.asoundrc.
this won't conflict with special apps like JACK, because they usually
open the hw layer directly.

as a future plan, we'll define dmix as default for el-cheapo
soundcards, but e.g. not for sb live, which supports such a function
on hardware.
so far, we leave it as user's own configuration, simply because dmix
had been under development and not quite stable.

well, there is still a problem that the ALSA's configuration is not
stream-wise.  a single definition is used for both playback and
capture directions.  this should be improved in the future.


Takashi


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Mark Hubbard]

On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> as a future plan, we'll define dmix as default for el-cheapo
> soundcards, but e.g. not for sb live, which supports such a function
> on hardware.

And what is your definition of an "el-cheapo" soundcard? :)

I object to this future plan as even users of consumer soundcards do not 
necessarily want everything resampled to 48 KHz in software by default with 
the inherent sound quality degradations. 

> so far, we leave it as user's own configuration, simply because dmix
> had been under development and not quite stable.

From the user's point of view, it is easier to build on the default settings 
than to deconstruct them in the asoundrc, thus, dmix should remain a 
non-default pcm. 

> well, there is still a problem that the ALSA's configuration is not
> stream-wise.  a single definition is used for both playback and
> capture directions.  this should be improved in the future.



-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Takashi Iwai]

At Fri, 14 Nov 2003 15:11:22 +0000,
Mark Hubbard wrote:
> 
> On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> > as a future plan, we'll define dmix as default for el-cheapo
> > soundcards, but e.g. not for sb live, which supports such a function
> > on hardware.
> 
> And what is your definition of an "el-cheapo" soundcard? :)
 
what requires dmix plugin :)

> I object to this future plan as even users of consumer soundcards do not 
> necessarily want everything resampled to 48 KHz in software by default with 
> the inherent sound quality degradations. 
 
hmm, we can implement it in a bit more clever way.  for example,
starting dmix with the sample rate of the first running process sets
(with lower boundary, e.g. the rate must be >= 44100).  in 99% time of
typical desktop usage, audio apps run alone, and no conversion will be
necessary.

of course, we need to fix the race condition, etc, to realize that.

> > so far, we leave it as user's own configuration, simply because dmix
> > had been under development and not quite stable.
> 
> From the user's point of view, it is easier to build on the default settings 
> than to deconstruct them in the asoundrc, thus, dmix should remain a 
> non-default pcm. 

the question is "which" user is targeted.
most desktop users need simple mixing only: playing mp3 or DVD and
beep.  hence, if the restriction of sampling-rate for a single app is
removed, there would be no big disadvantage to use always dmix.

and, note that we're discussing the "default" behavior.  you can
easily change it by defining your own default in ~/.asoundrc, as well
as you can set dmix for now.

i believe that the "usability" is a keyword to spread the linux
desktop over world.  we're still NOT in the way at all.


Takashi


-------------------------------------------------------
This SF.Net email sponsored by: ApacheCon 2003,
16-19 November in Las Vegas. Learn firsthand the latest
developments in Apache, PHP, Perl, XML, Java, MySQL,
WebDAV, and more! http://www.apachecon.com/

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Freitag, 14. November 2003 16:31 schrieb Takashi Iwai:
> At Fri, 14 Nov 2003 15:11:22 +0000,
>
> Mark Hubbard wrote:
> > On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> > > as a future plan, we'll define dmix as default for el-cheapo
> > > soundcards, but e.g. not for sb live, which supports such a function
> > > on hardware.
> >
> > And what is your definition of an "el-cheapo" soundcard? :)
OK,

now I understand that using what I suggested for *every* device alsa provides
is stupid (hw: should go directly to the hardware for low level application
etc.). Well, but as I see it the behavior for the "default" "front" "rear"
devices (the *normal* consumer applications use) could (and should in my
opinion) implement the behavior I suggest. But - I cant understand why you
are limiting down the use of dmix to "el-cheapo" soundcards - every soundcard
has in-hardware limitations for playback and capture...so dmix (and the
dnsoop part of my suggestion which you guys like to ignore :/) _can_ be
needed things for every/any card. And - if implemented in the *smart* way I
am talking about, dmix will only start mixing once the "default" "front" or
"rear" (assuming these are the only 3 devices *normal* applications should
use) cant handle another playback...Before that this "smartdmix" thing would
only pass through a untouched (same quality, no extra cpu usage, no extra
latency) stream. What you are talking about is the current (call it
stupid :P) dmixing, to just mix every stream that comes in, no matter if the
used device could handle the stream in hardware without mixing or not...which
of course gives you things like quality degression and unnecessary cpu usage
on cards that can playback more than one stream in hardware.

> the question is "which" user is targeted.
> most desktop users need simple mixing only: playing mp3 or DVD and
> beep.  hence, if the restriction of sampling-rate for a single app is
> removed, there would be no big disadvantage to use always dmix.
see above, always use smartdmix shouldnt be a problem for anybody - always
using dmix is (I must agree) plain stupid for high-end soundcards.

> and, note that we're discussing the "default" behavior.  you can
> easily change it by defining your own default in ~/.asoundrc, as well
> as you can set dmix for now.
>
> i believe that the "usability" is a keyword to spread the linux
> desktop over world.  we're still NOT in the way at all.
>
Right,

this is what Im talking about =). And the way I see my suggestion it will
offer great usability improvements for low-end soundcards, very view to
high-end soundcards, and never give any big disadvantages... :)


Peter
- --
Where does it go when you flush?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/tZOPg2ieGvTmHiURApD9AJ0Xxwx0mieCLmFa5z9tnmv5FmLD3wCZAU4e
qUSuQEVlYYHenzIXSylB/rE=
=IXw8
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Mark Hubbard]

On Friday 14 Nov 2003 15:31, Takashi Iwai wrote:
> At Fri, 14 Nov 2003 15:11:22 +0000, Mark Hubbard wrote:
> > On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> > > as a future plan, we'll define dmix as default for el-cheapo
> > > soundcards, but e.g. not for sb live, which supports such a function
> > > on hardware.
> >
> > And what is your definition of an "el-cheapo" soundcard? :)
>
> what requires dmix plugin :)

In that case, Audiotrak, Terratec and M-Audio sound cards are "el-cheapo", and 
Creative sound cards are "high quality"!

> > I object to this future plan as even users of consumer soundcards do not
> > necessarily want everything resampled to 48 KHz in software by default
> > with the inherent sound quality degradations.
>
> hmm, we can implement it in a bit more clever way.  for example,
> starting dmix with the sample rate of the first running process sets
> (with lower boundary, e.g. the rate must be >= 44100).  in 99% time of
> typical desktop usage, audio apps run alone, and no conversion will be
> necessary.
>
> of course, we need to fix the race condition, etc, to realize that.

Ah, I see, the "default dmix" will NOT have a fixed sample rate and as such it 
will work more like Window's KMixer. ;)



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Frank Barknecht]

Hallo,
Mark Hubbard hat gesagt: // Mark Hubbard wrote:

> On Friday 14 Nov 2003 15:31, Takashi Iwai wrote:
> > At Fri, 14 Nov 2003 15:11:22 +0000, Mark Hubbard wrote:
> > > And what is your definition of an "el-cheapo" soundcard? :)
> >
> > what requires dmix plugin :)
> 
> In that case, Audiotrak, Terratec and M-Audio sound cards are "el-cheapo", and 
> Creative sound cards are "high quality"!

Maybe a better term would be an "el-cheapo user". If someone buys an
RME card and then complains "Hey, I bought the most expensive card
supported by ALSA and now this crap can't even play two sounds at the
same time like my old Soundblasting AWE did" then that would define an
"el-cheapo user". ^_^

ciao
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Takashi Iwai]

At Mon, 17 Nov 2003 01:37:02 +0000,
Mark Hubbard wrote:
> 
> On Friday 14 Nov 2003 15:31, Takashi Iwai wrote:
> > At Fri, 14 Nov 2003 15:11:22 +0000, Mark Hubbard wrote:
> > > On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> > > > as a future plan, we'll define dmix as default for el-cheapo
> > > > soundcards, but e.g. not for sb live, which supports such a function
> > > > on hardware.
> > >
> > > And what is your definition of an "el-cheapo" soundcard? :)
> >
> > what requires dmix plugin :)
> 
> In that case, Audiotrak, Terratec and M-Audio sound cards are "el-cheapo", and 
> Creative sound cards are "high quality"!
 
ok, let me correct:  which users most likely want as dmix plugin :)


Takashi


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Takashi Iwai]

At Mon, 17 Nov 2003 14:34:14 +0100,
Peter Kirk wrote:
> 
> WARNING: Unsanitized content follows.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Montag, 17. November 2003 11:32 schrieb Takashi Iwai:
> > At Mon, 17 Nov 2003 01:37:02 +0000,
> > Mark Hubbard wrote:
> > > On Friday 14 Nov 2003 15:31, Takashi Iwai wrote:
> > > > At Fri, 14 Nov 2003 15:11:22 +0000, Mark Hubbard wrote:
> > > > > On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> > > > > > as a future plan, we'll define dmix as default for el-cheapo
> > > > > > soundcards, but e.g. not for sb live, which supports such a
> > > > > > function on hardware.
> >
> > ok, let me correct:  which users most likely want as dmix plugin :)
> >
> Hmmm,
> 
> sorry if I cant realy follow your reasoning. I have understood that using dmix 
> on every device is stupid - since some applications like jack want low level 
> access to the hardware. But these applications should use the hw: device, if 
> I understand everything right. If this is so, you have yet to come up for any 
> reason why a user would NOT want a smartdmix running behind devices like 
> "default" "rear" front" (and all others that I dont know about, but that are 
> consumer application devices) ?
> 
> Please enlighten me on this.

i personally think using dmix would be nice even for such "high-end"
cards.  but the smart dmix can still result in resampling or format
conversion if the first and the second applications use different
sample rates or formats.  in the case of cheap soundcards, it's not a
big problem because the quality is anyway cheap, too.  however, in the
case of high-end cards, people might not like that it happens.

this decision, whether dmix as default is better or not, depends on
users, not on us developers. 
the statement above simply shows this attitude.


Takashi


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Mark Hubbard]

On Monday 17 Nov 2003 14:33, Takashi Iwai wrote:
> At Mon, 17 Nov 2003 14:34:14 +0100,
>
> Peter Kirk wrote:
> > WARNING: Unsanitized content follows.
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Am Montag, 17. November 2003 11:32 schrieb Takashi Iwai:
> > > At Mon, 17 Nov 2003 01:37:02 +0000,
> > >
> > > Mark Hubbard wrote:
> > > > On Friday 14 Nov 2003 15:31, Takashi Iwai wrote:
> > > > > At Fri, 14 Nov 2003 15:11:22 +0000, Mark Hubbard wrote:
> > > > > > On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> > > > > > > as a future plan, we'll define dmix as default for el-cheapo
> > > > > > > soundcards, but e.g. not for sb live, which supports such a
> > > > > > > function on hardware.
> > >
> > > ok, let me correct:  which users most likely want as dmix plugin :)
> >
> > Hmmm,
> >
> > sorry if I cant realy follow your reasoning. I have understood that using
> > dmix on every device is stupid - since some applications like jack want
> > low level access to the hardware. But these applications should use the
> > hw: device, if I understand everything right. If this is so, you have yet
> > to come up for any reason why a user would NOT want a smartdmix running
> > behind devices like "default" "rear" front" (and all others that I dont
> > know about, but that are consumer application devices) ?
> >
> > Please enlighten me on this.
>
> i personally think using dmix would be nice even for such "high-end"
> cards.  but the smart dmix can still result in resampling or format
> conversion if the first and the second applications use different
> sample rates or formats.  in the case of cheap soundcards, it's not a
> big problem because the quality is anyway cheap, too.  however, in the
> case of high-end cards, people might not like that it happens.
>
> this decision, whether dmix as default is better or not, depends on
> users, not on us developers.
> the statement above simply shows this attitude.

Peter Kirk has an important point. Default dmix ("smart" could be a misnomer) 
will only work as the default pcm, therefore if one application is set-up to 
use surround51 and another set-up to use default, then nothing is going to be 
mixed. It would be better, for the sake of simplicity and ALSA's target user, 
to abandon the various pcm definitions and only use default which would work 
with all set-ups....I believe this is what Peter means by "smart".



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. November 2003 15:33 schrieb Takashi Iwai:
> At Mon, 17 Nov 2003 14:34:14 +0100,
>
> Peter Kirk wrote:
> > WARNING: Unsanitized content follows.
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Am Montag, 17. November 2003 11:32 schrieb Takashi Iwai:
> > > At Mon, 17 Nov 2003 01:37:02 +0000,
> > >
> > > Mark Hubbard wrote:
> > > > On Friday 14 Nov 2003 15:31, Takashi Iwai wrote:
> > > > > At Fri, 14 Nov 2003 15:11:22 +0000, Mark Hubbard wrote:
> > > > > > On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> > > > > > > as a future plan, we'll define dmix as default for el-cheapo
> > > > > > > soundcards, but e.g. not for sb live, which supports such a
> > > > > > > function on hardware.
> > >
> > > ok, let me correct:  which users most likely want as dmix plugin :)
> >
> > Hmmm,
> >
> > sorry if I cant realy follow your reasoning. I have understood that using
> > dmix on every device is stupid - since some applications like jack want
> > low level access to the hardware. But these applications should use the
> > hw: device, if I understand everything right. If this is so, you have yet
> > to come up for any reason why a user would NOT want a smartdmix running
> > behind devices like "default" "rear" front" (and all others that I dont
> > know about, but that are consumer application devices) ?
> >
> > Please enlighten me on this.
>
> i personally think using dmix would be nice even for such "high-end"
> cards.  but the smart dmix can still result in resampling or format
> conversion if the first and the second applications use different
> sample rates or formats.  in the case of cheap soundcards, it's not a
> big problem because the quality is anyway cheap, too.  however, in the
> case of high-end cards, people might not like that it happens.

if I understand it right, then "high-end" cards should be able to play 
multiple streams in hardware...meaning the smart dmix wouldnt even do 
anything else than pass on the streams to the soundcard (no resampling, no 
mixing, no nothing). Only if you play two streams on a soundcard that can 
only handle playing one, then it would mix (and resample if necessary for the 
mixing).

> this decision, whether dmix as default is better or not, depends on
> users, not on us developers.
> the statement above simply shows this attitude.
Well,

me being a user, I can tell you id realy love it (and I dont even have a 
*low*end* soundcard, for me only the dsnoop suggestion would make a 
difference.

Peter
- -- 
Who was that masked man?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/uREJg2ieGvTmHiURAp9BAKCLdCBQQE1Tq4xv58QAtFwQGiwCTQCdHZN5
s/Xr3/7ACgurLNBBhwVsZBs=
=Leq0
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. November 2003 18:16 schrieb Mark Hubbard:
> Peter Kirk has an important point. Default dmix ("smart" could be a
> misnomer) will only work as the default pcm, therefore if one application
> is set-up to use surround51 and another set-up to use default, then nothing
> is going to be mixed. It would be better, for the sake of simplicity and
> ALSA's target user, to abandon the various pcm definitions and only use
> default which would work with all set-ups....I believe this is what Peter
> means by "smart".
Well,

no smart dmix is no "misnomer". What I mean with it is: a implementation of 
dmix that only starts to mix if there is a need to do it - as long as the 
soundcard can handle streams without mixing the smart dmix will not do 
anything, except pass untouched streams to the hardware...when the first 
stream that would exceed hardware limitation is sent to the sound device, 
smart dmix would start mixing this stream into one of the existing ones.
You name a device I didnt know... "surround51". But, since this is what I call 
a "consumer app device", smart dmix would lure behind that too, and apply 
mixing magic if necessary.

Peter
- -- 
Don't vote -- it only encourages them!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/uRI6g2ieGvTmHiURAuJaAKCR3AR0xOCmTkC8sOig3kDkXgjB3gCeOtiD
Kp2fH2zKr+oLw3YAEECud9A=
=oGcT
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. November 2003 11:32 schrieb Takashi Iwai:
> At Mon, 17 Nov 2003 01:37:02 +0000,
> Mark Hubbard wrote:
> > On Friday 14 Nov 2003 15:31, Takashi Iwai wrote:
> > > At Fri, 14 Nov 2003 15:11:22 +0000, Mark Hubbard wrote:
> > > > On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> > > > > as a future plan, we'll define dmix as default for el-cheapo
> > > > > soundcards, but e.g. not for sb live, which supports such a
> > > > > function on hardware.
>
> ok, let me correct:  which users most likely want as dmix plugin :)
>
Hmmm,

sorry if I cant realy follow your reasoning. I have understood that using dmix
on every device is stupid - since some applications like jack want low level
access to the hardware. But these applications should use the hw: device, if
I understand everything right. If this is so, you have yet to come up for any
reason why a user would NOT want a smartdmix running behind devices like
"default" "rear" front" (and all others that I dont know about, but that are
consumer application devices) ?

Please enlighten me on this.
Peter
- --
If I could drop dead right now, I'd be the happiest man alive!
		-- Samuel Goldwyn

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/uRPGg2ieGvTmHiURArlnAJ4hc0CmdhQ2Cwh65eE0SdrFy0OH+QCeK0IK
2N60S6oaABtgTXhQVyc8rew=
=79E6
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Takashi Iwai]

At Mon, 17 Nov 2003 19:18:49 +0100,
Peter Kirk wrote:
> 
> WARNING: Unsanitized content follows.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Am Montag, 17. November 2003 15:33 schrieb Takashi Iwai:
> > At Mon, 17 Nov 2003 14:34:14 +0100,
> >
> > Peter Kirk wrote:
> > > WARNING: Unsanitized content follows.
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Am Montag, 17. November 2003 11:32 schrieb Takashi Iwai:
> > > > At Mon, 17 Nov 2003 01:37:02 +0000,
> > > >
> > > > Mark Hubbard wrote:
> > > > > On Friday 14 Nov 2003 15:31, Takashi Iwai wrote:
> > > > > > At Fri, 14 Nov 2003 15:11:22 +0000, Mark Hubbard wrote:
> > > > > > > On Friday 14 Nov 2003 13:20, Takashi Iwai wrote:
> > > > > > > > as a future plan, we'll define dmix as default for el-cheapo
> > > > > > > > soundcards, but e.g. not for sb live, which supports such a
> > > > > > > > function on hardware.
> > > >
> > > > ok, let me correct:  which users most likely want as dmix plugin :)
> > >
> > > Hmmm,
> > >
> > > sorry if I cant realy follow your reasoning. I have understood that using
> > > dmix on every device is stupid - since some applications like jack want
> > > low level access to the hardware. But these applications should use the
> > > hw: device, if I understand everything right. If this is so, you have yet
> > > to come up for any reason why a user would NOT want a smartdmix running
> > > behind devices like "default" "rear" front" (and all others that I dont
> > > know about, but that are consumer application devices) ?
> > >
> > > Please enlighten me on this.
> >
> > i personally think using dmix would be nice even for such "high-end"
> > cards.  but the smart dmix can still result in resampling or format
> > conversion if the first and the second applications use different
> > sample rates or formats.  in the case of cheap soundcards, it's not a
> > big problem because the quality is anyway cheap, too.  however, in the
> > case of high-end cards, people might not like that it happens.
> 
> if I understand it right, then "high-end" cards should be able to play 
> multiple streams in hardware...meaning the smart dmix wouldnt even do 
> anything else than pass on the streams to the soundcard (no resampling, no 
> mixing, no nothing). Only if you play two streams on a soundcard that can 
> only handle playing one, then it would mix (and resample if necessary for the 
> mixing).

well, my concern is that with the high-end cards, people tend to stick
with the quality of sounds.  that means, any reason to reduce the
quality wouldn't be acceptable for some people.  since dmix will do it
silently (if needed), it might be unacceptable.

anyway, it's just a concern.  the answer for this question would be
just a questionary to users (and a good documentation or user-friendly
GUI tool to configure).


Takashi


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Jaroslav Kysela]

On Mon, 17 Nov 2003, Peter Kirk wrote:

> WARNING: Unsanitized content follows.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Montag, 17. November 2003 18:16 schrieb Mark Hubbard:
> > Peter Kirk has an important point. Default dmix ("smart" could be a
> > misnomer) will only work as the default pcm, therefore if one application
> > is set-up to use surround51 and another set-up to use default, then nothing
> > is going to be mixed. It would be better, for the sake of simplicity and
> > ALSA's target user, to abandon the various pcm definitions and only use
> > default which would work with all set-ups....I believe this is what Peter
> > means by "smart".
> Well,
>
> no smart dmix is no "misnomer". What I mean with it is: a implementation of
> dmix that only starts to mix if there is a need to do it - as long as the
> soundcard can handle streams without mixing the smart dmix will not do
> anything, except pass untouched streams to the hardware...when the first
> stream that would exceed hardware limitation is sent to the sound device,
> smart dmix would start mixing this stream into one of the existing ones.

The problem is that it's not possible. If you have one application which
settled parameters with alsa-lib (and alsa driver) we cannot reroute this
stream to dmix. The dmix plugin works with some assumptions (predefined
parameters applied at start of first application) and all clients
(applications) must share same parameters, of course.

> You name a device I didnt know... "surround51". But, since this is what I call
> a "consumer app device", smart dmix would lure behind that too, and apply
> mixing magic if necessary.

It's not too easy.

I think that we should go in another direction. In my eyes, the best thing
would be to create a very user friendly (graphical) configuration tool for
alsa-lib which offers with a few clicks to choose dmix, plug or raw access
to devices. Many users want to do also some "additional" things like
stereo stream expansion to rear speakers and so on.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. November 2003 19:50 schrieb Jaroslav Kysela:
> On Mon, 17 Nov 2003, Peter Kirk wrote:
> > WARNING: Unsanitized content follows.
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Am Montag, 17. November 2003 18:16 schrieb Mark Hubbard:
> > > Peter Kirk has an important point. Default dmix ("smart" could be a
> > > misnomer) will only work as the default pcm, therefore if one
> > > application is set-up to use surround51 and another set-up to use
> > > default, then nothing is going to be mixed. It would be better, for the
> > > sake of simplicity and ALSA's target user, to abandon the various pcm
> > > definitions and only use default which would work with all set-ups....I
> > > believe this is what Peter means by "smart".
> >
> > Well,
> >
> > no smart dmix is no "misnomer". What I mean with it is: a implementation
> > of dmix that only starts to mix if there is a need to do it - as long as
> > the soundcard can handle streams without mixing the smart dmix will not
> > do anything, except pass untouched streams to the hardware...when the
> > first stream that would exceed hardware limitation is sent to the sound
> > device, smart dmix would start mixing this stream into one of the
> > existing ones.
>
> The problem is that it's not possible. If you have one application which
> settled parameters with alsa-lib (and alsa driver) we cannot reroute this
> stream to dmix. The dmix plugin works with some assumptions (predefined
> parameters applied at start of first application) and all clients
> (applications) must share same parameters, of course.

Ok,

what you say seems to be valid to me, but not if you implement smart dmix the
way I said =). The way I suggested *every* application would connect to smart
dmix, and none directly to alsa lib (except those that use devices like hw: -
and those should never be mixed). Since every stream is connected to smart
dmix, there is no need to *reroute* anything in the case of needed mixing.
The only thing that has to happen, is that the new stream, that has to be
mixed into the existing one due to hardware limitations has to be resampled
etc. to make mixing possible.
>
> > You name a device I didnt know... "surround51". But, since this is what I
> > call a "consumer app device", smart dmix would lure behind that too, and
> > apply mixing magic if necessary.
>
> It's not too easy.
>
> I think that we should go in another direction. In my eyes, the best thing
> would be to create a very user friendly (graphical) configuration tool for
> alsa-lib which offers with a few clicks to choose dmix, plug or raw access
> to devices. Many users want to do also some "additional" things like
> stereo stream expansion to rear speakers and so on.

In my eyes, configuration should only be necessary if there are any downsides
to an automagic sollution. As long as you dont convice me of some severe
missfeature my suggested smart dmix would impose on the users - there
shouldnt be any need for configuration.

Peter
- --
Always try to do things in chronological order; it's less confusing that way.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/uRyqg2ieGvTmHiURAhChAJ9JRoy1JtgbguMN8uBfDXNCxyBcVgCghw10
EvsraioHl1UOyiSPQzgcdsQ=
=1+6V
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. November 2003 19:49 schrieb Takashi Iwai:
> At Mon, 17 Nov 2003 19:18:49 +0100,
> Peter Kirk wrote:
> > Am Montag, 17. November 2003 15:33 schrieb Takashi Iwai:
> > if I understand it right, then "high-end" cards should be able to play
> > multiple streams in hardware...meaning the smart dmix wouldnt even do
> > anything else than pass on the streams to the soundcard (no resampling,
> > no mixing, no nothing). Only if you play two streams on a soundcard that
> > can only handle playing one, then it would mix (and resample if necessary
> > for the mixing).
>
> well, my concern is that with the high-end cards, people tend to stick
> with the quality of sounds.  that means, any reason to reduce the
> quality wouldn't be acceptable for some people.  since dmix will do it
> silently (if needed), it might be unacceptable.

what ? are you suggesting there are people out there that would rather have 
_NO_ sound instead of a (quality wise) slightly degraded sound ? I cant realy 
believe it :P. If they wanted to have maximum quality, they shouldnt open 
more soundstreams than their hardware can handle...

> anyway, it's just a concern.  the answer for this question would be
> just a questionary to users (and a good documentation or user-friendly
> GUI tool to configure).

well, at least I get your point now :). Maybe add a option that enables bypass 
of smart dmix for a device...but the default should be to use smart dmix, as 
most users I know wish to play the sounds that the applications they open 
play...

Peter
- -- 
Oh, well, I guess this is just going to be one of those lifetimes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/uR5/g2ieGvTmHiURAhK3AKCA+/zIAY0dOP9sPhLyAU13va1oEgCcDM1d
20wRl726T+iFG5WODfcKUrY=
=9gxW
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Paul Davis]

>what you say seems to be valid to me, but not if you implement smart dmix the
>way I said =). The way I suggested *every* application would connect to smart
>dmix, and none directly to alsa lib (except those that use devices like hw: -
>and those should never be mixed). Since every stream is connected to smart
>dmix, there is no need to *reroute* anything in the case of needed mixing.
>The only thing that has to happen, is that the new stream, that has to be
>mixed into the existing one due to hardware limitations has to be resampled
>etc. to make mixing possible.

believe or not, i actually think that peter is right here. if dmix
works well enough to be used by any application, then i think it
should be used for all non-hw accesses unless the user configures it
otherwise. if it doesn't work this well, it should :)

--p


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Paul Davis]

>> well, my concern is that with the high-end cards, people tend to stick
>> with the quality of sounds.  that means, any reason to reduce the
>> quality wouldn't be acceptable for some people.  since dmix will do it
>> silently (if needed), it might be unacceptable.
>
>what ? are you suggesting there are people out there that would rather have=
>=20
>_NO_ sound instead of a (quality wise) slightly degraded sound ? I cant rea=
>ly=20
>believe it :P. If they wanted to have maximum quality, they shouldnt open=
>=20
>more soundstreams than their hardware can handle...

the RME hardware has 16-26+ channels, but only one stream. 

--p



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. November 2003 20:40 schrieb Paul Davis:
> >> well, my concern is that with the high-end cards, people tend to stick
> >> with the quality of sounds.  that means, any reason to reduce the
> >> quality wouldn't be acceptable for some people.  since dmix will do it
> >> silently (if needed), it might be unacceptable.
> >
> >what ? are you suggesting there are people out there that would rather
> > have= =20
> >_NO_ sound instead of a (quality wise) slightly degraded sound ? I cant
> > rea= ly=20
> >believe it :P. If they wanted to have maximum quality, they shouldnt open=
> >=20
> >more soundstreams than their hardware can handle...
>
> the RME hardware has 16-26+ channels, but only one stream.

Ok,

here we come to my ignorance on sound drivers/hardware/terminology. If I talk 
about a stream I mean one application --> soundcard link. What would a 
channel be ? And what a stream if not what I defined a line up? 
Maybe this is off topic though, and propably I should google it.

Peter
- -- 
I'm so broke I can't even pay attention.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/uSYng2ieGvTmHiURAq/+AJwIb4RCu7cmw5Dzv6nni2nSKM7ihACeMEPw
CE3OSEeIJ8gDFwJjTtM9WRM=
=lhHZ
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Florian Schmidt]

On Mon, 17 Nov 2003 19:49:51 +0100
Takashi Iwai <tiwai@suse.de> wrote:

> anyway, it's just a concern.  the answer for this question would be
> just a questionary to users (and a good documentation or user-friendly
> GUI tool to configure).

As a user that has owned a cheapo soundcard before my current one i can
only say: I would have loved nothing more than hassle free software
mixing done automagically by alsa..

Sadly this doesn't solve all sound problems since many apps seem to have
still problems with dmix and it will take some time until app writers
adjust. But from my point of view this would be the right thing [tm].
Maybe it would also be possible to set dmix's parameters to more
"compatible" settings.. Maybe it even is with .asoundrc-magic..

I also don't know how good OSS emu can be used in conjunction with dmix.

Florian Schmidt


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Jaroslav Kysela]

On Mon, 17 Nov 2003, Paul Davis wrote:

> >what you say seems to be valid to me, but not if you implement smart dmix the
> >way I said =). The way I suggested *every* application would connect to smart
> >dmix, and none directly to alsa lib (except those that use devices like hw: -
> >and those should never be mixed). Since every stream is connected to smart
> >dmix, there is no need to *reroute* anything in the case of needed mixing.
> >The only thing that has to happen, is that the new stream, that has to be
> >mixed into the existing one due to hardware limitations has to be resampled
> >etc. to make mixing possible.
>
> believe or not, i actually think that peter is right here. if dmix
> works well enough to be used by any application, then i think it
> should be used for all non-hw accesses unless the user configures it
> otherwise. if it doesn't work this well, it should :)

Ok, maybe we all talk about same thing. Sure, if the code is matured
enough, we can use it as default. But I only want to note that dmix
- even with one stream - won't be ever equal to the raw hardware access
(hw:#,#).

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. November 2003 21:05 schrieb Jaroslav Kysela:
> On Mon, 17 Nov 2003, Paul Davis wrote:
> > >what you say seems to be valid to me, but not if you implement smart
> > > dmix the way I said =). The way I suggested *every* application would
> > > connect to smart dmix, and none directly to alsa lib (except those that
> > > use devices like hw: - and those should never be mixed). Since every
> > > stream is connected to smart dmix, there is no need to *reroute*
> > > anything in the case of needed mixing. The only thing that has to
> > > happen, is that the new stream, that has to be mixed into the existing
> > > one due to hardware limitations has to be resampled etc. to make mixing
> > > possible.
> >
> > believe or not, i actually think that peter is right here. if dmix
> > works well enough to be used by any application, then i think it
> > should be used for all non-hw accesses unless the user configures it
> > otherwise. if it doesn't work this well, it should :)
>
> Ok, maybe we all talk about same thing. Sure, if the code is matured
> enough, we can use it as default. But I only want to note that dmix
> - even with one stream - won't be ever equal to the raw hardware access
> (hw:#,#).

Hum,

about the "maturity" of dmix - I cant realy comment on it. All I know is, that 
it should be possible to do what I am suggesting eventualy. Since I am not a 
coder I dont have any idea on the restrictions/limitations of the current 
dmix implementation, and how hard it is to overcome them.
All I know is: Its possible, and you are the best guys on the job, so you can 
do it =). It would (in my opinion) be the biggest achievment in easiness to 
setup soundcards since many years. And its worth some effort to make it work.
How dmix would handle a single stream - I dont know why it should be modified 
by dmix. But appart from that, the "smartdmix" would just pass through single 
soundstreams, they wouldnt ever get near any dmixing...

Peter
- -- 
The Shuttle is now going five times the sound of speed.
		-- Dan Rather, first landing of Columbia
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/uS9cg2ieGvTmHiURAkiIAJ46SAlueVdrPsSyL594m+iiUitm5wCeN0SF
9gUG4BsY1zNnCPNaruOjLso=
=Wzuy
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Paul Davis]

>On Mon, 17 Nov 2003, Paul Davis wrote:
>
>> >what you say seems to be valid to me, but not if you implement smart dmix t
>he
>> >way I said =). The way I suggested *every* application would connect to sma
>rt
>> >dmix, and none directly to alsa lib (except those that use devices like hw:
> -
>> >and those should never be mixed). Since every stream is connected to smart
>> >dmix, there is no need to *reroute* anything in the case of needed mixing.
>> >The only thing that has to happen, is that the new stream, that has to be
>> >mixed into the existing one due to hardware limitations has to be resampled
>> >etc. to make mixing possible.
>>
>> believe or not, i actually think that peter is right here. if dmix
>> works well enough to be used by any application, then i think it
>> should be used for all non-hw accesses unless the user configures it
>> otherwise. if it doesn't work this well, it should :)
>
>Ok, maybe we all talk about same thing. Sure, if the code is matured
>enough, we can use it as default. But I only want to note that dmix
>- even with one stream - won't be ever equal to the raw hardware access
>(hw:#,#).

note that i said "for all non-hw accesses"
			 ^^^^^^^^

applications that open "hw:N" should know what they are doing, and
why. 


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Paul Davis]

>> the RME hardware has 16-26+ channels, but only one stream.
>
>Ok,
>
>here we come to my ignorance on sound drivers/hardware/terminology. If I ta=
>lk=20
>about a stream I mean one application --> soundcard link. What would a=20
>channel be ? And what a stream if not what I defined a line up?=20
>Maybe this is off topic though, and propably I should google it.

a stream is an independently controllable data path. on the RME cards,
you can't stop and start channel 19 etc. - the whole thing runs as one
engine. as a result, the ALSA hw driver doesn't create multiple
streams for the device - even if one app is only using 2 of the many
available channels. this is intentional.

--p


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[James Courtier-Dutton]

Hi,

Just a general comment on dmix/dsnoop.
1) It is not bug free yet. I have an application that fails when one 
tries to use it. (xine.sf.net). I have not had time to establish why 
yet. E.g. xine using "front" device, output's stereo sounding perfectly. 
I note down the buffer and period sizes and rate and sample format being 
used for "front" and set "dmix" to use the same via the alsa.conf file.
But playing with "dmix" causes the sound to stutter, as though only 
every second period is being played, with zero samples in between.
When I get a moment I will investigate further the exact cause. 
Initially I thought it was a buffer/period size problem, but I have 
checked that, and that is not the problem. The next TODO test I will do 
will be testing the snd_pcm_delay() returned from the dmix device, and 
compare it's accuracy with "front".

2) For smart dmix/dsnoop to be really user friendly, we will need a 
version of it that works in full duplex. I.E. Multiple applications able 
to record the same stream as well as play to it at the same time.

3) If one application wishes to play to "surround51" and a different 
application wishes to play to "front", dmix will have to be clever 
enought to mix the two.

4) If one application wishes to play to "front" and a different 
application wishes to play to "rear", the mixer should be able to mix to 
get 4 output channels.

5) I think that this sound mixing problem might be better served by 
sound servers like jack.

6) software mixing is ok, but software resampling is not a good idea to 
do in alsa-lib, because a) It cannot do good quality resamplings because 
t is trying to keep latency low. b) A audio/video application could do 
resampling better because it could do it at the decoding stages, before 
latency and audio/video sync is a problem.

7) For mixing, each open of the alsa multi-open device should have it's 
own volume control per open, and not just the hardware backend volume 
controls. The application could easily control their own volume, without 
effecting other application's volume.

Summary: -
An application should be able to use device names like "rear", "front", 
"surround51" and then have a separate control to tell alsa whether it is 
allowed to do resampling or not. Then at least the more advanced 
application could decide for itself whether to use alsa-lib's low 
quality resampler, or implement it's own multi-tap interpolation filter.
For a video/audio application like xine.sf.net, being able to open the 
alsa device in such a way to ensure we know where the sound will be 
routed(which speakers sound will come from) is useful.

Cheers
James



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Peter Kirk]

WARNING: Unsanitized content follows.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Montag, 17. November 2003 22:58 schrieb James Courtier-Dutton:
> Hi,
>
> Just a general comment on dmix/dsnoop.
> 1) It is not bug free yet.

right. It would be great if you guys that have some overview would map out 
some basic "TODO" - where all outstanding bugs and all missfeatures that need 
fixing would be listed. That way progress could be monitored, and people that 
would want to help on this task would quickly see what there is to do.

> 2) For smart dmix/dsnoop to be really user friendly, we will need a
> version of it that works in full duplex. I.E. Multiple applications able
> to record the same stream as well as play to it at the same time.
Well,

what I gathered from talking to people, dmix is for playback and dsnoop is for 
capture. Thats why I suggest to implement this using those two 
plugins...because I thought this would give us full duplex. So yes, full 
duplex support for as many application as the user wishes is definetly 
something that my feature suggestion should achieve when implemented.

> 3) If one application wishes to play to "surround51" and a different
> application wishes to play to "front", dmix will have to be clever
> enought to mix the two.

correct.

> 4) If one application wishes to play to "front" and a different
> application wishes to play to "rear", the mixer should be able to mix to
> get 4 output channels.

agreed.

> 5) I think that this sound mixing problem might be better served by
> sound servers like jack.

Hmmm,

actualy I did have a very close look at jack, but the problem that I saw 
(correct me if Im wrong here), is the fact that jack only works well if the 
applications are specificaly geard to work with it. To quote the FAQ:

#How can I make my app use Jack?
#Your app must be callback-based. This means that you shouldn't block on 
#writes or reads from a PCM device; rather, you should have your app be 
#"driven" by a function that gets called at regular intervals. This is a 
#design decision. Then, take a look at the simple client code, and do your 
#interesting stuff inside the process() function. 
#Note that code written for any callback API can generally be ported to any 
#other callback API fairly easily. Code that is written around a "blocking I/
#O" model generally needs to completely redesigned to be used in any kind of 
#callback API.

Because of this I tossed the idea of using jack for this asside - and found 
dmix/dnsoop. Now you might say: Its open source, just wait until all the 
applications are adapted to use jack. But, even if everybody would be 
convinced of the necessity - it would take a long time. Also one of my main 
interests for this whole mixing thing is voice-communication alongside with 
games. And you might know that (closed source) games like quake3, unreal 
tournament 2003 etc. will just NOT get any special jack support in it 
anymore, especially since theyd needed to be "completly redesigned". 

> 6) software mixing is ok, but software resampling is not a good idea to
> do in alsa-lib, because a) It cannot do good quality resamplings because
> t is trying to keep latency low. b) A audio/video application could do
> resampling better because it could do it at the decoding stages, before
> latency and audio/video sync is a problem.

Ok, Im not the guy that knows about the workings of alsa-driver, but I guess 
currently  a application like xine *knows* what sample rate the soundcards 
supports, and then gives alsa-lib a soundstream that is sampled to that 
specific rate ? If this would be the case, then nothing would change if smart 
dmix/dnsoop would be implemented. If the only playback stream is already 
taken, with sample rate "X", then alsa-lib would tell xine, that the 
soundcard [currently] only supports sample rate "X" in hardware - and xine 
would do the resampling to "X". Only if a application that doesnt care to 
investigate what samplerates are supported just sends sound to alsa-lib, in 
sample rate "Y", then resampling would have to be done.
If I understand it correctly, then current alsa-lib will resample if 
necessary. To quote the .asoundrc wiki:

#Which automatically converts your samples to a 44.1 kHz sample rate while 
#playing. It's not very useful because most players and alsa converts samples 
#to the right sample rate which your soundcard is capable of, but you can use 
#it for a conversion to a lower static sample rate for example.

There would be no change in this behavior, except that it might be necessary 
more often (in the cases where alsa-lib currently says "no way stream, 
soundcard is full").

> 7) For mixing, each open of the alsa multi-open device should have it's
> own volume control per open, and not just the hardware backend volume
> controls. The application could easily control their own volume, without
> effecting other application's volume.

This extends my feature suggestion, but its IMHO a great idea. If this is 
possible and viable, go for it too =).

> Summary: -
> An application should be able to use device names like "rear", "front",
> "surround51" and then have a separate control to tell alsa whether it is
> allowed to do resampling or not. Then at least the more advanced
> application could decide for itself whether to use alsa-lib's low
> quality resampler, or implement it's own multi-tap interpolation filter.
> For a video/audio application like xine.sf.net, being able to open the
> alsa device in such a way to ensure we know where the sound will be
> routed(which speakers sound will come from) is useful.

sounds right. I realy hope you guys can do this.

Peter
- -- 
Everyone wants results, but no one is willing to do what it takes to get them.
		-- Dirty Harry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/ubNvg2ieGvTmHiURAmt0AJ4suWE18CpAVTd0bWwwJw6qYN9KiwCfbKoD
JUquoVkakeAfLrm26zVff78=
=Fn3b
-----END PGP SIGNATURE-----



-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl

Re: smart and automatic use of dmix and dsnoop - feature suggestion.

[Paul Davis]

>> 5) I think that this sound mixing problem might be better served by
>> sound servers like jack.
>
>Hmmm,
>
>actualy I did have a very close look at jack, but the problem that I saw=20
>(correct me if Im wrong here), is the fact that jack only works well if the=
>=20
>applications are specificaly geard to work with it. To quote the FAQ:

this isn't an issue any more, in that ALSA supports output via JACK
itself. apps don't behave the way real JACK clients would, but the
sound is heard. i don't know if capture support works.

jack is not intended to be a general purpose solution though. although
i believe that its callback API is a better choice, things like
PortAudio offer that with or without JACK. jack's main offering is low
latency, sample synchronous execution. i guess if it really worked for
everybody, it would be great. chances are that it might be slightly
closer to working than dmix, but i don't really know (especially the
capture part). making connections is also difficult - it puts quite a
burden on the user.

--p


-------------------------------------------------------
This SF. Net email is sponsored by: GoToMyPC
GoToMyPC is the fast, easy and secure way to access your computer from
any Web browser or wireless device. Click here to Try it Free!
https://www.gotomypc.com/tr/OSDN/AW/Q4_2003/t/g22lp?Target=mm/g22lp.tmpl