DMIX and capture stream

DMIX and capture stream

[David Lloyd]

I'm working on changing DMIX to allow clients to open the capture stream.  
But I've hit a bit of a block with how to proceed.  Since it would seem
that a slave snd_pcm_t can only be opened either for capture or playback,
it would seem to follow that one would need a second handle to be able to
open both ways.  Is that correct?

Based on this assumption, I added a 'scappcm' member to the u.dmix member 
of snd_pcm_direct_t.  This would be the handle used for capture stream 
opens.  It would not be shareable like the playback stream (at least not 
yet).  Is this a reasonable approach?

I was thinking about copying out the read routines from pcm_plugin.c and 
editing them to use u.dmix.scappcm for reading.  Will this approach work 
or will I have to make dramatic changes?  Is anyone here willing to take 
some time and check over my work, maybe point me in the right direction?

Thanks for the help.

- D


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Paul Davis]

>I'm working on changing DMIX to allow clients to open the capture stream.  

i don't get it. dmix is for playback, not capture. what would be the
semantics of this?

--p


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Joern Nettingsmeier]

Paul Davis wrote:
>>I'm working on changing DMIX to allow clients to open the capture stream.  
> 
> 
> i don't get it. dmix is for playback, not capture. what would be the
> semantics of this?

haven't tried yet, but isn't "dsnoop" the dmix equivalent for capture ?


-- 
In this house, we obey the laws of thermodynamics!
	- Homer Simpson

Jörn Nettingsmeier
Kurfürstenstr 49, 45138 Essen, Germany
http://spunk.dnsalias.org (my server)
http://www.linuxaudiodev.org (Linux Audio Developers)





-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id\x1278&alloc_id371&op=click

Re: DMIX and capture stream

[Florian Schmidt]

On Sun, 04 Jan 2004 00:07:26 -0500
Paul Davis <paul@linuxaudiosystems.com> wrote:

> >I'm working on changing DMIX to allow clients to open the capture
> >stream.  
> 
> i don't get it. dmix is for playback, not capture. what would be the
> semantics of this?

Hmm, i don't know the OP's answer to this, but i like to ask a very
related question:

It is possible to create a playback pcm device with the help of the dmix
plugin. This way several apps can playback at once - nice. But now what
about using two apps that do full duplex at the same time?

It is also possible to create a readable pcm device with the help of the
dsnoop plugin. This way several apps can record at once..

But the question is: How do i combine those two, so that i have a pcm
device that is readable and writeable by multiple clients on a soundcard
that does not support hw mixing of neither capture nor playback streams.
And how do i get OSS emu to work with it. I suppose i will need to alter
the pcm.dsp0 device to use that dmix/dsnoop combined device..

Flo

-- 
music: http://www.soundclick.com/bands/9/florianschmidt.htm




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[David Lloyd]

On Sun, 4 Jan 2004, Florian Schmidt wrote:

> On Sun, 04 Jan 2004 00:07:26 -0500
> Paul Davis <paul@linuxaudiosystems.com> wrote:
> 
> > >I'm working on changing DMIX to allow clients to open the capture
> > >stream.  
> > 
> > i don't get it. dmix is for playback, not capture. what would be the
> > semantics of this?
> 
> Hmm, i don't know the OP's answer to this, but i like to ask a very
> related question:
> 
> It is possible to create a playback pcm device with the help of the dmix
> plugin. This way several apps can playback at once - nice. But now what
> about using two apps that do full duplex at the same time?

This is exacly my point.  The fact that dmix and dsnoop are half-duplex is
where I have a problem.  There seems to be no way to allow more than one
OSS-compatibility client to share audio in a satisfactory way.  Which is
to say, you can have two doing playback, or two doing capture, or maybe
one each (haven't tried yet), but you can't do two full-duplex, or one
full-duplex and one capture or playback.  This is a bug in my opinion.  
It seems to me that this issue is not addressed by anyone, and that's why 
I started this code change, to allow capture to "pass through" so that one 
client can do full-duplex with multiple other clients still able to 
playback.  This is not too much to ask IMHO.

But at this point, I'm so disgusted I think I'll just buy a card with a 
hardware mixer like an SBLive, and forget about the whole thing.  It looks 
like the plugin mechanism is completely ignorant of full-duplex 
applications anyway.  I think that if a sound device doesn't have hardware 
mixing, it should be emulated in the kernel.  I know a lot of people don't 
thing that's as "clean" as using a plugin, but it would make the life of 
the end-user a lot nicer.

Have a nice day.

- D


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Florian Schmidt]

On Sun, 4 Jan 2004 18:02:11 -0600 (CST)
David Lloyd <dmlloyd@tds.net> wrote:

> This is exacly my point.  The fact that dmix and dsnoop are
> half-duplex is where I have a problem.  There seems to be no way to
> allow more than one OSS-compatibility client to share audio in a
> satisfactory way.  Which is to say, you can have two doing playback,
> or two doing capture, or maybe one each (haven't tried yet), but you
> can't do two full-duplex, or one full-duplex and one capture or
> playback.  This is a bug in my opinion.  It seems to me that this
> issue is not addressed by anyone, and that's why I started this code
> change, to allow capture to "pass through" so that one client can do
> full-duplex with multiple other clients still able to playback.  This
> is not too much to ask IMHO.
> 
> But at this point, I'm so disgusted I think I'll just buy a card with
> a hardware mixer like an SBLive, and forget about the whole thing.  It
> looks like the plugin mechanism is completely ignorant of full-duplex 
> applications anyway.  I think that if a sound device doesn't have
> hardware mixing, it should be emulated in the kernel.  I know a lot of
> people don't thing that's as "clean" as using a plugin, but it would
> make the life of the end-user a lot nicer.

I don't know, if the plugin layer is completely ignorant of full duplex
applications. Maybe there's just one little thing missing in the whole
picture:

A plugin somewhat similar to the multi-plugin that knows how to combine
writable and readable pcm devices into one writable/readable one.

Another approach would be, like you said, to create a virtual soundcard
that does nothing else than providing sw mixing for another "real"
card...

I'm not a kernel hacker, so i don't know anythig about the challenges of
creating such a driver. I assume that the first way is easier..

Flo

-- 
music: http://www.soundclick.com/bands/9/florianschmidt.htm




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Patrick Shirkey]

David Lloyd wrote:
> On Sun, 4 Jan 2004, Florian Schmidt wrote:
> 
> 
>>On Sun, 04 Jan 2004 00:07:26 -0500
>>Paul Davis <paul@linuxaudiosystems.com> wrote:
>>
>>
>>>>I'm working on changing DMIX to allow clients to open the capture
>>>>stream.  
>>>
>>>i don't get it. dmix is for playback, not capture. what would be the
>>>semantics of this?
>>
>>Hmm, i don't know the OP's answer to this, but i like to ask a very
>>related question:
>>
>>It is possible to create a playback pcm device with the help of the dmix
>>plugin. This way several apps can playback at once - nice. But now what
>>about using two apps that do full duplex at the same time?
> 
> 
> This is exacly my point.  The fact that dmix and dsnoop are half-duplex is
> where I have a problem.  There seems to be no way to allow more than one
> OSS-compatibility client to share audio in a satisfactory way.  Which is
> to say, you can have two doing playback, or two doing capture, or maybe
> one each (haven't tried yet), but you can't do two full-duplex, or one
> full-duplex and one capture or playback.  This is a bug in my opinion.  
> It seems to me that this issue is not addressed by anyone, and that's why 
> I started this code change, to allow capture to "pass through" so that one 
> client can do full-duplex with multiple other clients still able to 
> playback.  This is not too much to ask IMHO.
>

Recent discussion of this has made it clear that in the near future 
Jaroslav and Takashi are planning on implementing better 
interoperability between dmix and dsnoop.

It's not high on the list of priorities because there are already other 
software mixing apps/deamons that work. It is high on the list of 
desired features though :)

As you have found out the changes required are not superficial but 
require advanced understanding of ALSA internals.

dmix and dsnoop are less than a year old and there are still apps that 
don't provide correct support for them. If you can't wait, you could try 
  to use JACK, artsd, gstreamer....


-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================


  Apparently upon the beginning of the barrage, the donkey broke 
discipline and panicked, toppling the cart. At that point, the rockets 
disconnected from the timer, leaving them strewn around the street. 
Tethered to the now toppled cart, the donkey was unable to escape before 
the arrival of U.S. troops.

United Press International
Rockets on donkeys hit major Baghdad sites

By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

HDSP as normal user.

[Patrick Shirkey]

Using latest cvs I am unable to run the hdsp as a normal user. It works 
as root user however.

Any ideas for fixing this?


-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================


  Apparently upon the beginning of the barrage, the donkey broke 
discipline and panicked, toppling the cart. At that point, the rockets 
disconnected from the timer, leaving them strewn around the street. 
Tethered to the now toppled cart, the donkey was unable to escape before 
the arrival of U.S. troops.

United Press International
Rockets on donkeys hit major Baghdad sites

By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: HDSP as normal user.

[Paul Davis]

>Using latest cvs I am unable to run the hdsp as a normal user. It works 
>as root user however.
>
>Any ideas for fixing this?

more specifics about what doesn't work would be helpful.


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: HDSP as normal user.

[Takashi Iwai]

At Mon, 05 Jan 2004 19:18:44 +0900,
Patrick Shirkey wrote:
> 
> Using latest cvs I am unable to run the hdsp as a normal user. It works 
> as root user however.
> 
> Any ideas for fixing this?

this sounds like a permission problem.
check the permission of /dev/snd/* files.

on some systems, the permission of these files is changed dynamically
at each login over xdm via PAM.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: HDSP as normal user.

[Patrick Shirkey]

Takashi Iwai wrote:
> At Mon, 05 Jan 2004 19:18:44 +0900,
> Patrick Shirkey wrote:
> 
>>Using latest cvs I am unable to run the hdsp as a normal user. It works 
>>as root user however.
>>
>>Any ideas for fixing this?
> 
> 
> this sounds like a permission problem.
> check the permission of /dev/snd/* files.
> 
> on some systems, the permission of these files is changed dynamically
> at each login over xdm via PAM.
> 

Hmm, seems I had to completely logout for my changes to the perms to 
have effect. Thanks for the tip.

I'll add something to the online docs about this.



-- 
Patrick Shirkey - Boost Hardware Ltd.
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================


  Apparently upon the beginning of the barrage, the donkey broke 
discipline and panicked, toppling the cart. At that point, the rockets 
disconnected from the timer, leaving them strewn around the street. 
Tethered to the now toppled cart, the donkey was unable to escape before 
the arrival of U.S. troops.

United Press International
Rockets on donkeys hit major Baghdad sites

By P. MITCHELL PROTHERO
Published 11/21/2003 11:13 AM



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[David Lloyd]

On Mon, 5 Jan 2004, Patrick Shirkey wrote:

> David Lloyd wrote:
>
> Recent discussion of this has made it clear that in the near future
> Jaroslav and Takashi are planning on implementing better
> interoperability between dmix and dsnoop.
> 
> It's not high on the list of priorities because there are already other
> software mixing apps/deamons that work. It is high on the list of
> desired features though :)

But these mixers do not work for all applications; the application has to 
support it.  Therefore I wouldn't say they "work", becuase they do not 
solve the problem of allowing multiple applications to use the sound 
device without having to be coded up specially.

I still think the proper solution is to come up with a kernel module that
provides software mixing capabilities to sound drivers for cards without
hardware mixers.  The sound drivers for these cards should then be updated
to use the mixer module.  This is much simpler from the end-user's
perspective.  I think that using the plugin system for this is incorrect.  
After all, why should one user have to set up a complicated dmix/dsnoop
setup (which doesn't even work yet) when the next user can use a simple,
basic configuration, with the only difference being the sound card?  The
average user isn't going to know that one card has a hardware mixer and
another doesnt.

- D


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Jaroslav Kysela]

On Mon, 5 Jan 2004, David Lloyd wrote:

> On Mon, 5 Jan 2004, Patrick Shirkey wrote:
> 
> > David Lloyd wrote:
> >
> > Recent discussion of this has made it clear that in the near future
> > Jaroslav and Takashi are planning on implementing better
> > interoperability between dmix and dsnoop.
> > 
> > It's not high on the list of priorities because there are already other
> > software mixing apps/deamons that work. It is high on the list of
> > desired features though :)
> 
> But these mixers do not work for all applications; the application has to 
> support it.  Therefore I wouldn't say they "work", becuase they do not 
> solve the problem of allowing multiple applications to use the sound 
> device without having to be coded up specially.

No and no and no. The 90% percent of problems are caused that the dmix, 
dsnoop and dshare plugins have special setup to debug / show the 
communication problems with the ALSA applications.

I am sure that most of ALSA applications work without any modification. 
Other applications are badly coded and these plugins simply show the 
problems with them. That's ok. Tell the application developers that 
they do not follow API.

OSS emulation has different problems, because their mmap() / fragment 
implementation has restrictions which are difficult to follow in some 
cases. But I think that if the buffering parameters are set correctly, 
many applications will also work.

The third major problem is rate resampling. The most of cheap cards work 
only with 48kHz. I will dig to this problem more deeply in the near 
future.

Having the mixing code in the kernel is only a new pain which does not 
solve the problem. If there's a bug in dmix, it's easy to solve it. It's 
much more easy than doing this job in the kernel.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Jaroslav Kysela]

On Mon, 5 Jan 2004, David Lloyd wrote:

> On Sun, 4 Jan 2004, Paul Davis wrote:
> 
> > >I'm working on changing DMIX to allow clients to open the capture stream.  
> > 
> > i don't get it. dmix is for playback, not capture. what would be the
> > semantics of this?
> 
> That is exactly the problem!  DMIX is for playback.  DSNOOP is for 
> capture.  Where is the module that is for both?  Why, oh why, did they not 
> simply make ONE MODULE in the first place??

Both are logically separate, because they're doing absolutely different 
things.

> The semantics would be (rather would have been) that if someone tries to
> open the capture stream through the dmix plugin, it will "pass through" to
> the slave.  This means that while many apps can open playback stream, only 
> one would be able to open capture without blocking.
> 
> It would have been ideal to integrate dsnoop functionality, but I deemed 
> that this was a bit too complicated for an initial implementation.
> 
> Of course at this point, I'm ready to forget it.  I've got too many things 
> going on to justify not just buying a new sound card, much as that 
> irritates me.

What's your problems? ALSA applications should offer you to set the 
playback and capture devices independently. If you bother with the OSS 
emulation, simply change the code in oss_dsp_open() - alsa-oss/alsa-oss.c.
Perhaps, we can do it for you.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[David Lloyd]

On Sun, 4 Jan 2004, Paul Davis wrote:

> >I'm working on changing DMIX to allow clients to open the capture stream.  
> 
> i don't get it. dmix is for playback, not capture. what would be the
> semantics of this?

That is exactly the problem!  DMIX is for playback.  DSNOOP is for 
capture.  Where is the module that is for both?  Why, oh why, did they not 
simply make ONE MODULE in the first place??

The semantics would be (rather would have been) that if someone tries to
open the capture stream through the dmix plugin, it will "pass through" to
the slave.  This means that while many apps can open playback stream, only 
one would be able to open capture without blocking.

It would have been ideal to integrate dsnoop functionality, but I deemed 
that this was a bit too complicated for an initial implementation.

Of course at this point, I'm ready to forget it.  I've got too many things 
going on to justify not just buying a new sound card, much as that 
irritates me.

- D


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Takashi Iwai]

At Mon, 5 Jan 2004 10:29:01 -0600 (CST),
David Lloyd wrote:
> 
> On Sun, 4 Jan 2004, Paul Davis wrote:
> 
> > >I'm working on changing DMIX to allow clients to open the capture stream.  
> > 
> > i don't get it. dmix is for playback, not capture. what would be the
> > semantics of this?
> 
> That is exactly the problem!  DMIX is for playback.  DSNOOP is for 
> capture.  Where is the module that is for both?  Why, oh why, did they not 
> simply make ONE MODULE in the first place??

patch welcome ;)

well, more practical answer is that capturing the playback would need 
copy of the playback data to the capture buffer.  meanwhile, the
implementation of dmix and dsnoop is basically only the multiplex
access of a single hardware buffer.  it's not "copying" of data.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Takashi Iwai]

At Mon, 5 Jan 2004 17:28:33 +0100 (CET),
Jaroslav wrote:
> 
> > The semantics would be (rather would have been) that if someone tries to
> > open the capture stream through the dmix plugin, it will "pass through" to
> > the slave.  This means that while many apps can open playback stream, only 
> > one would be able to open capture without blocking.
> > 
> > It would have been ideal to integrate dsnoop functionality, but I deemed 
> > that this was a bit too complicated for an initial implementation.
> > 
> > Of course at this point, I'm ready to forget it.  I've got too many things 
> > going on to justify not just buying a new sound card, much as that 
> > irritates me.
> 
> What's your problems? ALSA applications should offer you to set the 
> playback and capture devices independently. If you bother with the OSS 
> emulation, simply change the code in oss_dsp_open() - alsa-oss/alsa-oss.c.
> Perhaps, we can do it for you.

i guess he's mentioning loopback, which we haven't implemented yet?


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[David Lloyd]

On Mon, 5 Jan 2004, Takashi Iwai wrote:

> At Mon, 5 Jan 2004 10:29:01 -0600 (CST),
> David Lloyd wrote:
> > 
> > On Sun, 4 Jan 2004, Paul Davis wrote:
> > 
> > > >I'm working on changing DMIX to allow clients to open the capture stream.  
> > > 
> > > i don't get it. dmix is for playback, not capture. what would be the
> > > semantics of this?
> > 
> > That is exactly the problem!  DMIX is for playback.  DSNOOP is for 
> > capture.  Where is the module that is for both?  Why, oh why, did they not 
> > simply make ONE MODULE in the first place??
> 
> patch welcome ;)
> 
> well, more practical answer is that capturing the playback would need 
> copy of the playback data to the capture buffer.  meanwhile, the
> implementation of dmix and dsnoop is basically only the multiplex
> access of a single hardware buffer.  it's not "copying" of data.

Nonononono.  Nobody is understanding what I want!

I have application A that needs to open payback and capture streams 
because it's a two-way communications program.  Application B is a game 
that uses playback only.  I want to use these both at the same time.

Problem is both applications use OSS emulation.  They both work with aoss, 
but the two-way program won't initialize sound when dmix is loaded because 
it's not allowed to open capture stream.  See my problem?  I can't put two 
different plugins in my audiorc and expect an OSS application to 
understand it.  I am not interested in capturing the playback stream!  I 
just want to have more than one program be able to use /dev/dsp for both 
input and output...

- D


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[David Lloyd]

On Mon, 5 Jan 2004, Jaroslav Kysela wrote:

> What's your problems? ALSA applications should offer you to set the
> playback and capture devices independently. If you bother with the OSS
> emulation, simply change the code in oss_dsp_open() -
> alsa-oss/alsa-oss.c. Perhaps, we can do it for you.

That is EXACTLY what I want.  Exactly!  And that is what I will try next, 
but if you want to do it it would be greatly appreciated.

- D


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Florian Schmidt]

On Mon, 5 Jan 2004 17:28:33 +0100 (CET)
Jaroslav Kysela <perex@suse.cz> wrote:

> > That is exactly the problem!  DMIX is for playback.  DSNOOP is for 
> > capture.  Where is the module that is for both?  Why, oh why, did
> > they not simply make ONE MODULE in the first place??
> 
> Both are logically separate, because they're doing absolutely
> different things.

Hmm, but they are very closely related in that they "share" access to a
soundcard. In one case it is for playback and the other for capture.
They are yin and yang. one mixes, the other distributes..

To make life simpler for users i think there should be a way to combine
these two into one pcm device that has all the goodies in one..  point
the OSS emu to it and you are ready to use two OSS apps at once [which
is _not_ possible at the moment, if one of the OSS apps wants to capture
audio additionally to the playback]

> What's your problems? ALSA applications should offer you to set the 
> playback and capture devices independently. 

> If you bother with the OSS
> emulation, simply change the code in oss_dsp_open() -
> alsa-oss/alsa-oss.c. Perhaps, we can do it for you.

Sorry, i'm not sure i understood you here. Do you mean you want to
change the OSS emu to have it use different pcm devices for playback and
capture? This would make combining dmix/dsnoop into one plugin
unnessecary. If that was your message, then please, please, pretty
please, with whipped cream on top, do so.. And if you don't have the
time for it, maybe some pointers to us all would be useful so we can
burn our hands on it... I don't know though how this would be specified
via the .asoundrc. As far as i know it is not possible to use two slaves
for a pcm device..

I have a hw mixing soundcard, but i think this is very important for
ALSA.. Hangout one day in #alsa and you will agree..

Flo

P.S.: Actually i think this really is all about the oss emu, since like
you said, correctly written alsa apps should let you select different
pcm's for playback and capture.. But i wonder:  how many are correctly
written and are facts like this documented in some alsa-developer infos?

-- 
music: http://www.soundclick.com/bands/9/florianschmidt.htm




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Paul Davis]

>I have application A that needs to open payback and capture streams 
>because it's a two-way communications program.  Application B is a game 
>that uses playback only.  I want to use these both at the same time.

but i don't think you can do this with OSS. why should ALSA's OSS
emulation make it possible? the OSS API doesn't support this. if they
used the ALSA API, it would work without (much) work on your part.

--p




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[David Lloyd]

On Mon, 5 Jan 2004, Paul Davis wrote:

> >I have application A that needs to open payback and capture streams 
> >because it's a two-way communications program.  Application B is a game 
> >that uses playback only.  I want to use these both at the same time.
> 
> but i don't think you can do this with OSS. why should ALSA's OSS
> emulation make it possible? the OSS API doesn't support this. if they
> used the ALSA API, it would work without (much) work on your part.

I agree, that would be fantastic, but many commercial apps only support 
OSS, and it will be long before they change.  So are you saying that you 
want ALSA's OSS emulation to not use any ALSA features, just because OSS 
didn't provide it?  That sounds a bit weak to me.  From what Jaroslav was 
saying this is actully pretty wasy to do, so why not do it?

- D


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Takashi Iwai]

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

At Mon, 05 Jan 2004 12:41:12 -0500,
Paul Davis wrote:
> 
> >I have application A that needs to open payback and capture streams 
> >because it's a two-way communications program.  Application B is a game 
> >that uses playback only.  I want to use these both at the same time.
> 
> but i don't think you can do this with OSS. why should ALSA's OSS
> emulation make it possible? the OSS API doesn't support this. if they
> used the ALSA API, it would work without (much) work on your part.

ok, finally i got his question - well, i didn't read carefully it
before, since i still have 5,000 unread mails...

anyway, it's possible if you use aoss wrapper and specify dmix/dsnoop
as the device.  you're right for the kernel emulation.  no way.
but still we need a fix for aoss wrapper.  the only necessary change
is to allow aoss open different pcm per playback and capture stream.

for example, the below is a minute quick hack (untested) for that.
you can specify pcm.dsp0p and pcm.dsp0c for playback and capture
directions, respectively.


Takashi

[-- Attachment #2: alsa-oss-duplex.dif --]
[-- Type: application/octet-stream, Size: 1015 bytes --]

Index: alsa-oss/alsa-oss.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-oss/alsa-oss.c,v
retrieving revision 1.24
diff -u -r1.24 alsa-oss.c
--- alsa-oss/alsa-oss.c	1 Dec 2003 13:25:58 -0000	1.24
+++ alsa-oss/alsa-oss.c	5 Jan 2004 18:08:18 -0000
@@ -394,6 +394,7 @@
 	int fd = -1;
 	int result;
 	char name[64];
+	static char *suffix[2] = { "p", "c" };
 
 	switch (device) {
 	case OSS_DEVICE_DSP:
@@ -447,11 +448,16 @@
 	dsp->oss_format = format;
 	result = -EINVAL;
 	for (k = 0; k < 2; ++k) {
+		char tmpname[64];
 		if (!(streams & (1 << k)))
 			continue;
-		result = snd_pcm_open(&dsp->streams[k].pcm, name, k, pcm_mode);
-		if (result < 0)
-			break;
+		snprintf(tmpname, sizeof(tmpname), "%s%s", name, suffix[k]);
+		result = snd_pcm_open(&dsp->streams[k].pcm, tmpname, k, pcm_mode);
+		if (result < 0) {
+			result = snd_pcm_open(&dsp->streams[k].pcm, name, k, pcm_mode);
+			if (result < 0)
+				break;
+		}
 	}
 	if (result < 0) {
 		result = 0;

Re: DMIX and capture stream

[Paul Davis]

>> >I have application A that needs to open payback and capture streams 
>> >because it's a two-way communications program.  Application B is a game 
>> >that uses playback only.  I want to use these both at the same time.
>> 
>> but i don't think you can do this with OSS. why should ALSA's OSS
>> emulation make it possible? the OSS API doesn't support this. if they
>> used the ALSA API, it would work without (much) work on your part.
>
>I agree, that would be fantastic, but many commercial apps only support 
>OSS, and it will be long before they change.  So are you saying that you 
>want ALSA's OSS emulation to not use any ALSA features, just because OSS 
>didn't provide it?  That sounds a bit weak to me.  From what Jaroslav was 
>saying this is actully pretty wasy to do, so why not do it?

it cannot be done via direct kernel emulation (ie. the app has to be
run by "aoss"). kernel emulation has no access to the relevant user
space plugins.

and anyway, no, actually i don't think ALSA should waste time on this
when it was not possible under OSS. all it does is prop up apps using
the OSS API, and thats a bad idea from every angle.

--p


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[David Lloyd]

On Mon, 5 Jan 2004, Takashi Iwai wrote:

> anyway, it's possible if you use aoss wrapper and specify dmix/dsnoop as
> the device.  you're right for the kernel emulation.  no way. but still
> we need a fix for aoss wrapper.  the only necessary change is to allow
> aoss open different pcm per playback and capture stream.
>
> for example, the below is a minute quick hack (untested) for that. you
> can specify pcm.dsp0p and pcm.dsp0c for playback and capture directions,
> respectively.

This patch works great - I'm now able to use TeamSpeak (which opens 
capture and playback through oss) at the same time as xmms.

- D


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Florian Schmidt]

On Tue, 6 Jan 2004 11:05:52 -0600 (CST)
David Lloyd <dmlloyd@tds.net> wrote:

> This patch works great - I'm now able to use TeamSpeak (which opens 
> capture and playback through oss) at the same time as xmms.
> 

Cool.. this sounds good. Great news! Thanks, Takashi.. Is there a chance
of this getting into cvs? Is this actually a replacement for the
pcm.dspX definition? or is it still possible to define it the old way?

Flo

P.S.: I myself didn't try it, cause my SC does hw mixing anyway..

-- 
hrrrm! 



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Takashi Iwai]

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

At Tue, 6 Jan 2004 22:38:28 +0100,
Florian Schmidt wrote:
> 
> On Tue, 6 Jan 2004 11:05:52 -0600 (CST)
> David Lloyd <dmlloyd@tds.net> wrote:
> 
> > This patch works great - I'm now able to use TeamSpeak (which opens 
> > capture and playback through oss) at the same time as xmms.
> > 
> 
> Cool.. this sounds good. Great news! Thanks, Takashi.. Is there a chance
> of this getting into cvs? Is this actually a replacement for the
> pcm.dspX definition? or is it still possible to define it the old way?

as written in my previous mail, it was a quick hack.  and there is a
better approach.

the attached patch will add a new plugin, asym, which defines
different slave pcms for playback and capture streams.
for example,

	pcm.duplex {
		type asym
		playback.pcm "dmix"
		capture.pcm "dsnoop"
	}

then you can use the pcm "duplex" for dmix/dsnoop combination.

	% aplay -D duplex foo.wav
	% arecord -D duplex bar.wav

(in reality, you likely need plug layer in addition to support other
 sample rates, though.)

also, by defining

	pcm.dsp0 "duplex"

you can use it via aoss, too.


i'm not sure whether the name "asym" is the best choice.
if you have better idea, please let me know before committing to cvs.


Takashi

[-- Attachment #2: pcm-asym.dif --]
[-- Type: application/octet-stream, Size: 5528 bytes --]

Index: alsa-lib/src/pcm/Makefile.am
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/pcm/Makefile.am,v
retrieving revision 1.40
diff -u -r1.40 Makefile.am
--- alsa-lib/src/pcm/Makefile.am	17 Sep 2003 17:03:14 -0000	1.40
+++ alsa-lib/src/pcm/Makefile.am	7 Jan 2004 10:53:54 -0000
@@ -11,7 +11,7 @@
 	            pcm_shm.c pcm_file.c pcm_null.c pcm_share.c \
 		    pcm_meter.c pcm_hooks.c pcm_lfloat.c pcm_ladspa.c \
 		    pcm_direct.c pcm_dmix.c pcm_dsnoop.c pcm_dshare.c \
-		    pcm_symbols.c
+		    pcm_asym.c pcm_symbols.c
 noinst_HEADERS = pcm_local.h pcm_plugin.h mask.h mask_inline.h \
 	         interval.h interval_inline.h plugin_ops.h ladspa.h \
 		 pcm_direct.h pcm_dmix_i386.h pcm_dmix_x86_64.h
Index: alsa-lib/src/pcm/pcm.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/pcm/pcm.c,v
retrieving revision 1.141
diff -u -r1.141 pcm.c
--- alsa-lib/src/pcm/pcm.c	2 Jan 2004 13:41:32 -0000	1.141
+++ alsa-lib/src/pcm/pcm.c	7 Jan 2004 10:54:29 -0000
@@ -1782,7 +1782,7 @@
 static char *build_in_pcms[] = {
 	"adpcm", "alaw", "copy", "dmix", "file", "hooks", "hw", "ladspa", "lfloat",
 	"linear", "meter", "mulaw", "multi", "null", "plug", "rate", "route", "share",
-	"shm", "dsnoop", "dshare", NULL
+	"shm", "dsnoop", "dshare", "asym", NULL
 };
 
 static int snd_pcm_open_conf(snd_pcm_t **pcmp, const char *name,
Index: alsa-lib/src/pcm/pcm_symbols.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/pcm/pcm_symbols.c,v
retrieving revision 1.9
diff -u -r1.9 pcm_symbols.c
--- alsa-lib/src/pcm/pcm_symbols.c	20 Mar 2003 11:06:14 -0000	1.9
+++ alsa-lib/src/pcm/pcm_symbols.c	7 Jan 2004 10:54:07 -0000
@@ -43,6 +43,7 @@
 extern const char *_snd_module_pcm_dmix;
 extern const char *_snd_module_pcm_dsnoop;
 extern const char *_snd_module_pcm_dshare;
+extern const char *_snd_module_pcm_asym;
 
 static const char **snd_pcm_open_objects[] = {
 	&_snd_module_pcm_adpcm,
@@ -65,7 +66,8 @@
 	&_snd_module_pcm_ladspa,
 	&_snd_module_pcm_dmix,
 	&_snd_module_pcm_dsnoop,
-	&_snd_module_pcm_dshare
+	&_snd_module_pcm_dshare,
+	&_snd_module_pcm_asym
 };
 	
 void *snd_pcm_open_symbols(void)
--- /dev/null	2003-11-13 06:41:21.000000000 +0100
+++ alsa-lib/src/pcm/pcm_asym.c	2004-01-07 11:53:43.000000000 +0100
@@ -0,0 +1,115 @@
+/**
+ * \file pcm/pcm_asym.c
+ * \ingroup PCM_Plugins
+ * \brief PCM Asym Plugin Interface
+ * \author Takashi Iwai <tiwai@suse.de>
+ * \date 2003
+ */
+
+#include "pcm_local.h"
+
+#ifndef PIC
+/* entry for static linking */
+const char *_snd_module_pcm_asym = "";
+#endif
+
+/*! \page pcm_plugins
+
+\section pcm_plugins_asym Plugin: asym
+
+This plugin is a combination of playback and capture PCM streams.
+Assymmetrical slave PCMs can be defined for both directions.
+
+\code
+pcm.name {
+        type asym               # Asym PCM
+        playback STR            # Playback slave name
+        # or
+        playback {              # Playback slave definition
+                pcm STR         # Slave PCM name
+                # or
+                pcm { }         # Slave PCM definition
+        }
+        capture STR             # Capture slave name
+        # or
+        capture {               # Capture slave definition
+                pcm STR         # Slave PCM name
+                # or
+                pcm { }         # Slave PCM definition
+        }
+}
+\endcode
+
+For example, you can combine a dmix plugin and a dsnoop plugin as
+as a single PCM for playback and capture directions, respectively.
+\code
+pcm.duplex {
+	type asym
+	playback.pcm "dmix"
+	capture.pcm "dsnoop"
+}
+\endcode
+
+\subsection pcm_plugins_asym_funcref Function reference
+
+<UL>
+  <LI>_snd_pcm_asym_open()
+</UL>
+
+*/
+
+/**
+ * \brief Creates a new asym stream PCM
+ * \param pcmp Returns created PCM handle
+ * \param name Name of PCM
+ * \param root Root configuration node
+ * \param conf Configuration node with copy PCM description
+ * \param stream Stream type
+ * \param mode Stream mode
+ * \retval zero on success otherwise a negative error code
+ * \warning Using of this function might be dangerous in the sense
+ *          of compatibility reasons. The prototype might be freely
+ *          changed in future.
+ */
+int _snd_pcm_asym_open(snd_pcm_t **pcmp, const char *name ATTRIBUTE_UNUSED,
+			 snd_config_t *root, snd_config_t *conf,
+			 snd_pcm_stream_t stream, int mode)
+{
+	snd_config_iterator_t i, next;
+	int err;
+	snd_config_t *slave = NULL, *sconf;
+	snd_config_for_each(i, next, conf) {
+		snd_config_t *n = snd_config_iterator_entry(i);
+		const char *id;
+		if (snd_config_get_id(n, &id) < 0)
+			continue;
+		if (snd_pcm_conf_generic_id(id))
+			continue;
+		if (strcmp(id, "playback") == 0) {
+			if (stream == SND_PCM_STREAM_PLAYBACK)
+				slave = n;
+			continue;
+		}
+		if (strcmp(id, "capture") == 0) {
+			if (stream == SND_PCM_STREAM_CAPTURE)
+				slave = n;
+			continue;
+		}
+		SNDERR("Unknown field %s", id);
+		return -EINVAL;
+	}
+	if (! slave) {
+		SNDERR("%s slave is not defined",
+		       stream == SND_PCM_STREAM_PLAYBACK ? "playback" : "capture");
+		return -EINVAL;
+	}
+	err = snd_pcm_slave_conf(root, slave, &sconf, 0);
+	if (err < 0)
+		return err;
+	err = snd_pcm_open_slave(pcmp, root, sconf, stream, mode);
+	snd_config_delete(sconf);
+	return err;
+}
+#ifndef DOC_HIDDEN
+SND_DLSYM_BUILD_VERSION(_snd_pcm_asym_open, SND_PCM_DLSYM_VERSION);
+#endif

Re: DMIX and capture stream

[Florian Schmidt]

On Wed, 07 Jan 2004 12:01:02 +0100
Takashi Iwai <tiwai@suse.de> wrote:

> as written in my previous mail, it was a quick hack.  and there is a
> better approach.
> 
> the attached patch will add a new plugin, asym, which defines
> different slave pcms for playback and capture streams.
> for example,
> 
> 	pcm.duplex {
> 		type asym
> 		playback.pcm "dmix"
> 		capture.pcm "dsnoop"
> 	}
> 

Ah, ok. This solution makes even more sense, since it is more generally
useful. Especially for [broken] alsa apps that don't let you specify
seperate pcm's for playback/capture..

I think of this plugin as making a full duplex pcm out of two half
duplex pcm. So why not call the plugin "duplexer"?

Flo

P.S.: One question that comes up though: What happens when you specify a
full duplex device as one of the two pcm's? Will there be an error msg?
Or maybe some of the "multi" functionality could be used...

-- 
hrrrm! 



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Abramo Bagnara]

Takashi Iwai wrote:

> as written in my previous mail, it was a quick hack.  and there is a
> better approach.

I'd prefer the following approach:

pcmp.duplex {
	type dmix
	...
}

pcmc.duplex {
	type dsnoop
	...
}

with the following policy:
- if capture is specified pcmc and pcm are searched in this order
- if playback is specified pcmp and pcm are searched in this order

This would solve also the annoying problem of pcm that are valid only 
for one direction and should not be used (or browsed) for the other.


-- 
Abramo Bagnara                       mailto:abramo.bagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Florian Schmidt]

On Wed, 7 Jan 2004 13:05:30 +0100
Florian Schmidt <mista.tapas@gmx.net> wrote:

> I think of this plugin as making a full duplex pcm out of two half
> duplex pcm. So why not call the plugin "duplexer"?


Btw: This plugin reminds me somewhat of the "multi" plugin since it,
too, combines several pcm's into one. maybe the functionality could be
merged..

Flo

-- 
hrrrm! 



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Takashi Iwai]

At Wed, 07 Jan 2004 13:45:05 +0100,
Abramo Bagnara wrote:
> 
> Takashi Iwai wrote:
> 
> > as written in my previous mail, it was a quick hack.  and there is a
> > better approach.
> 
> I'd prefer the following approach:
> 
> pcmp.duplex {
> 	type dmix
> 	...
> }
> 
> pcmc.duplex {
> 	type dsnoop
> 	...
> }
> 
> with the following policy:
> - if capture is specified pcmc and pcm are searched in this order
> - if playback is specified pcmp and pcm are searched in this order

this was my first idea, too.

but i'm afraid that it will lead to more conditionals (i.e. more
codes) over all plugins with a slave pcm, and make the syntax more
complicated.


> This would solve also the annoying problem of pcm that are valid only 
> for one direction and should not be used (or browsed) for the other.

it's also possible by defining only playback or capture

	pcm.playbackonly {
		type asym
		playback.pcm foo
	}

then the rest stream will remain undefined.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Takashi Iwai]

At Wed, 7 Jan 2004 14:06:22 +0100,
Florian Schmidt wrote:
> 
> On Wed, 7 Jan 2004 13:05:30 +0100
> Florian Schmidt <mista.tapas@gmx.net> wrote:
> 
> > I think of this plugin as making a full duplex pcm out of two half
> > duplex pcm. So why not call the plugin "duplexer"?

"duplex" was my first idea, too :)
but i thought it sounds too generic for the purpose.
namely, this plugin can behave also as half-duplex.

if other people prefer it, i'll rename it of course, though.


> 
> Btw: This plugin reminds me somewhat of the "multi" plugin since it,
> too, combines several pcm's into one. maybe the functionality could be
> merged..

i don't think so.  the beautiful point of this plugin is that it
doesn't affect other codes at all.  that is, you can use safely your
old settings.

of course, extension of multi plugin would be easy, but i don't see
big merits by that.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Abramo Bagnara]

Takashi Iwai wrote:
> At Wed, 07 Jan 2004 13:45:05 +0100,
> Abramo Bagnara wrote:
> 
>>Takashi Iwai wrote:
>>
>>
>>>as written in my previous mail, it was a quick hack.  and there is a
>>>better approach.
>>
>>I'd prefer the following approach:
>>
>>pcmp.duplex {
>>	type dmix
>>	...
>>}
>>
>>pcmc.duplex {
>>	type dsnoop
>>	...
>>}
>>
>>with the following policy:
>>- if capture is specified pcmc and pcm are searched in this order
>>- if playback is specified pcmp and pcm are searched in this order
> 
> 
> this was my first idea, too.
> 
> but i'm afraid that it will lead to more conditionals (i.e. more
> codes) over all plugins with a slave pcm, and make the syntax more
> complicated.

I don't see your point, can you show me an example of what you mean?

AFAICS the only code that need to be changed is the PCM definition lookup.

-- 
Abramo Bagnara                       mailto:abramo.bagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Takashi Iwai]

At Wed, 07 Jan 2004 15:39:14 +0100,
Abramo Bagnara wrote:
> 
> Takashi Iwai wrote:
> > At Wed, 07 Jan 2004 13:45:05 +0100,
> > Abramo Bagnara wrote:
> > 
> >>Takashi Iwai wrote:
> >>
> >>
> >>>as written in my previous mail, it was a quick hack.  and there is a
> >>>better approach.
> >>
> >>I'd prefer the following approach:
> >>
> >>pcmp.duplex {
> >>	type dmix
> >>	...
> >>}
> >>
> >>pcmc.duplex {
> >>	type dsnoop
> >>	...
> >>}
> >>
> >>with the following policy:
> >>- if capture is specified pcmc and pcm are searched in this order
> >>- if playback is specified pcmp and pcm are searched in this order
> > 
> > 
> > this was my first idea, too.
> > 
> > but i'm afraid that it will lead to more conditionals (i.e. more
> > codes) over all plugins with a slave pcm, and make the syntax more
> > complicated.
> 
> I don't see your point, can you show me an example of what you mean?
> 
> AFAICS the only code that need to be changed is the PCM definition lookup.

there are two parts to be modified, snd_pcm_open_noupdate() and
snd_pcm_slave_conf().  they are the parts which look up "pcm"
directive in the configuration.
the former is easy.  but the latter function doesn't have stream
argument, so it cannot check whether "pcmp" or "pcmc" to check.  and,
changing this function will need rewriting all callers...


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Abramo Bagnara]

Takashi Iwai wrote:
> At Wed, 07 Jan 2004 15:39:14 +0100,
> Abramo Bagnara wrote:
> 
>>
>>I don't see your point, can you show me an example of what you mean?
>>
>>AFAICS the only code that need to be changed is the PCM definition lookup.
> 
> 
> there are two parts to be modified, snd_pcm_open_noupdate() and
> snd_pcm_slave_conf().  they are the parts which look up "pcm"
> directive in the configuration.
> the former is easy.  but the latter function doesn't have stream
> argument, so it cannot check whether "pcmp" or "pcmc" to check.  and,
> changing this function will need rewriting all callers...

I definitely don't see why you think snd_pcm_slave_conf need to be 
changed. It does not need to know about pcmp/pcmc variants.

I'm missing something?


-- 
Abramo Bagnara                       mailto:abramo.bagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Takashi Iwai]

At Wed, 07 Jan 2004 16:15:40 +0100,
Abramo Bagnara wrote:
> 
> Takashi Iwai wrote:
> > At Wed, 07 Jan 2004 15:39:14 +0100,
> > Abramo Bagnara wrote:
> > 
> >>
> >>I don't see your point, can you show me an example of what you mean?
> >>
> >>AFAICS the only code that need to be changed is the PCM definition lookup.
> > 
> > 
> > there are two parts to be modified, snd_pcm_open_noupdate() and
> > snd_pcm_slave_conf().  they are the parts which look up "pcm"
> > directive in the configuration.
> > the former is easy.  but the latter function doesn't have stream
> > argument, so it cannot check whether "pcmp" or "pcmc" to check.  and,
> > changing this function will need rewriting all callers...
> 
> I definitely don't see why you think snd_pcm_slave_conf need to be 
> changed. It does not need to know about pcmp/pcmc variants.
> 
> I'm missing something?

if i understand the code correctly, for defining a pcmp or pcmc as a
slave pcm, such as,

	pcm.foo {
		type plug
		slave {
			pcmp bar_playback
			pcmc bar_capture
		}
	}

snd_pcm_slave_conf() needs to know which one to be used, so that the
config subtree (of either pcmp, pcmc or pcm) is passed to
snd_pcm_open_slave().

otherwise, you have to define slave pcms always separetly, such as,

	pcm.foo {
		type plug
		slave {
			pcm bar
		}
	}
	pcmp.bar bar_playback
	pcmc.bar bar_capture

i think it's a big restriction.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click

Re: DMIX and capture stream

[Abramo Bagnara]

Takashi Iwai wrote:
> 
> 
> if i understand the code correctly, for defining a pcmp or pcmc as a
> slave pcm, such as,
> 
> 	pcm.foo {
> 		type plug
> 		slave {
> 			pcmp bar_playback
> 			pcmc bar_capture
> 		}
> 	}
> 
> snd_pcm_slave_conf() needs to know which one to be used, so that the
> config subtree (of either pcmp, pcmc or pcm) is passed to
> snd_pcm_open_slave().
> 
> otherwise, you have to define slave pcms always separetly, such as,
> 
> 	pcm.foo {
> 		type plug
> 		slave {
> 			pcm bar
> 		}
> 	}
> 	pcmp.bar bar_playback
> 	pcmc.bar bar_capture
> 
> i think it's a big restriction.

As a matter of personal preference I very much prefer this latter form 
(as it leave capture and playback definition clearly separated as 
directions are in ALSA API).

Under an "objective" point of view: would you really derive from the 
comparison of the two equivalent alternative syntaxes the feeling of "a 
big restriction"?

Technically they're quite the same.

-- 
Abramo Bagnara                       mailto:abramo.bagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: DMIX and capture stream

[Takashi Iwai]

At Wed, 07 Jan 2004 16:47:53 +0100,
Abramo Bagnara wrote:
> 
> Takashi Iwai wrote:
> > 
> > 
> > if i understand the code correctly, for defining a pcmp or pcmc as a
> > slave pcm, such as,
> > 
> > 	pcm.foo {
> > 		type plug
> > 		slave {
> > 			pcmp bar_playback
> > 			pcmc bar_capture
> > 		}
> > 	}
> > 
> > snd_pcm_slave_conf() needs to know which one to be used, so that the
> > config subtree (of either pcmp, pcmc or pcm) is passed to
> > snd_pcm_open_slave().
> > 
> > otherwise, you have to define slave pcms always separetly, such as,
> > 
> > 	pcm.foo {
> > 		type plug
> > 		slave {
> > 			pcm bar
> > 		}
> > 	}
> > 	pcmp.bar bar_playback
> > 	pcmc.bar bar_capture
> > 
> > i think it's a big restriction.
> 
> As a matter of personal preference I very much prefer this latter form 

i do, too.

> (as it leave capture and playback definition clearly separated as 
> directions are in ALSA API).

hmm, the first example is also enough clear, i feel :)

> Under an "objective" point of view: would you really derive from the 
> comparison of the two equivalent alternative syntaxes the feeling of "a 
> big restriction"?

well, i admit "big" is a too big word.
but it means that the inline definition isn't equivalent any longer
with the external definition, since you cannot express the
playback/capture-only pcm in the inline slave pcm.  that's what i'm
concerned.


> Technically they're quite the same.

also my asym plugin, too :)  it doesn't introduce any overhead except
for parsing.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: DMIX and capture stream

[Abramo Bagnara]

Takashi Iwai wrote:
>>>
>>>	pcm.foo {
>>>		type plug
>>>		slave {
>>>			pcm bar
>>>		}
>>>	}
>>>	pcmp.bar bar_playback
>>>	pcmc.bar bar_capture
>>>
>>>i think it's a big restriction.
>>
>>As a matter of personal preference I very much prefer this latter form 
> 
> 
> i do, too.
> 
> but it means that the inline definition isn't equivalent any longer
> with the external definition, since you cannot express the
> playback/capture-only pcm in the inline slave pcm.  that's what i'm
> concerned.

This is true only inside duplex PCM definition and I like to consider 
that a feature, i.e. duplex definition should be the same for both 
directions.

>>Technically they're quite the same.
> 
> 
> also my asym plugin, too :)  it doesn't introduce any overhead except
> for parsing.

It's true but I'd prefer to not have too many PCM types.

Take also in account that the association between playback stream and 
capture stream is definitely arbitrary and a well written duplex ALSA 
native application should ask for two PCM names.

I fear that this extension will encourage bad programming practice.

Thinking further, I've changed my mind: what about to have an OSS 
emulation specific configuration?

Just like:

aoss_pcm_w.dsp0 dmix
aoss_pcm_r.dsp0 dsnoop

I think it's a far better solution and will leave native library intact.

-- 
Abramo Bagnara                       mailto:abramo.bagnara@tin.it

Opera Unica                          Phone: +39.0546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy



-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: DMIX and capture stream

[Takashi Iwai]

At Wed, 07 Jan 2004 17:58:10 +0100,
Abramo Bagnara wrote:
> 
> Takashi Iwai wrote:
> >>>
> >>>	pcm.foo {
> >>>		type plug
> >>>		slave {
> >>>			pcm bar
> >>>		}
> >>>	}
> >>>	pcmp.bar bar_playback
> >>>	pcmc.bar bar_capture
> >>>
> >>>i think it's a big restriction.
> >>
> >>As a matter of personal preference I very much prefer this latter form 
> > 
> > 
> > i do, too.
> > 
> > but it means that the inline definition isn't equivalent any longer
> > with the external definition, since you cannot express the
> > playback/capture-only pcm in the inline slave pcm.  that's what i'm
> > concerned.
> 
> This is true only inside duplex PCM definition and I like to consider 
> that a feature, i.e. duplex definition should be the same for both 
> directions.
> 
> >>Technically they're quite the same.
> > 
> > 
> > also my asym plugin, too :)  it doesn't introduce any overhead except
> > for parsing.
> 
> It's true but I'd prefer to not have too many PCM types.

well, apparently it became now the argument of tastes.
technically they are almost identical.

time for vote?


> Take also in account that the association between playback stream and 
> capture stream is definitely arbitrary and a well written duplex ALSA 
> native application should ask for two PCM names.

the problem appears also when you want to define a generic pcm name,
such as iec958.  for example, iec1712 has different number of channels
for playback and capture directions (capture has the digital mix
channels), and thus the definition of iec958 must be different between
playback and capture.  in the current code, it's not allowed.
because the definition of iec958 is valid only for playback, so far,
you cannot record the spdif on ice1712 like

	% arecord -Diec958 foo.wav

similarly, it would be nice to have such a feature (duplexing) if you
want override the "default" pcm together with dmix and dsnoop.

> I fear that this extension will encourage bad programming practice.

understood.  we should stress this in the documents.

> Thinking further, I've changed my mind: what about to have an OSS 
> emulation specific configuration?
> 
> Just like:
> 
> aoss_pcm_w.dsp0 dmix
> aoss_pcm_r.dsp0 dsnoop

oh yeah, that's similar with my first patch ;)

> I think it's a far better solution and will leave native library intact.

but it's also true that there is definitely a merit (even fix) by
having duplex feature like above.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html

Re: DMIX and capture stream

[Jaroslav Kysela]

On Wed, 7 Jan 2004, Takashi Iwai wrote:

> there are two parts to be modified, snd_pcm_open_noupdate() and
> snd_pcm_slave_conf().  they are the parts which look up "pcm"
> directive in the configuration.
> the former is easy.  but the latter function doesn't have stream
> argument, so it cannot check whether "pcmp" or "pcmc" to check.  and,
> changing this function will need rewriting all callers...

I agree with Takashi. The configuration scheme will be probably changed in
the future in favor of the integrated lisp interpreter which allows us to
better describe the plugin connections and handle the runtime stuff much
better. So, please, keep things simple. The standalone plugin looks as the 
best solution for the moment.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html