* DMIX and capture stream @ 2004-01-02 20:29 David Lloyd 2004-01-04 5:07 ` Paul Davis 0 siblings, 1 reply; 41+ messages in thread From: David Lloyd @ 2004-01-02 20:29 UTC (permalink / raw) To: ALSA Mailing List 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-02 20:29 DMIX and capture stream David Lloyd @ 2004-01-04 5:07 ` Paul Davis 2004-01-04 12:12 ` Joern Nettingsmeier ` (2 more replies) 0 siblings, 3 replies; 41+ messages in thread From: Paul Davis @ 2004-01-04 5:07 UTC (permalink / raw) To: David Lloyd; +Cc: ALSA Mailing List >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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-04 5:07 ` Paul Davis @ 2004-01-04 12:12 ` Joern Nettingsmeier 2004-01-04 13:52 ` Florian Schmidt 2004-01-05 16:29 ` David Lloyd 2 siblings, 0 replies; 41+ messages in thread From: Joern Nettingsmeier @ 2004-01-04 12:12 UTC (permalink / raw) To: Paul Davis, ALSA development 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-04 5:07 ` Paul Davis 2004-01-04 12:12 ` Joern Nettingsmeier @ 2004-01-04 13:52 ` Florian Schmidt 2004-01-05 0:02 ` David Lloyd 2004-01-05 16:29 ` David Lloyd 2 siblings, 1 reply; 41+ messages in thread From: Florian Schmidt @ 2004-01-04 13:52 UTC (permalink / raw) To: Paul Davis; +Cc: dmlloyd, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-04 13:52 ` Florian Schmidt @ 2004-01-05 0:02 ` David Lloyd 2004-01-05 0:15 ` Florian Schmidt 2004-01-05 6:00 ` Patrick Shirkey 0 siblings, 2 replies; 41+ messages in thread From: David Lloyd @ 2004-01-05 0:02 UTC (permalink / raw) To: Florian Schmidt; +Cc: Paul Davis, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 0:02 ` David Lloyd @ 2004-01-05 0:15 ` Florian Schmidt 2004-01-05 6:00 ` Patrick Shirkey 1 sibling, 0 replies; 41+ messages in thread From: Florian Schmidt @ 2004-01-05 0:15 UTC (permalink / raw) To: David Lloyd; +Cc: paul, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 0:02 ` David Lloyd 2004-01-05 0:15 ` Florian Schmidt @ 2004-01-05 6:00 ` Patrick Shirkey 2004-01-05 10:18 ` HDSP as normal user Patrick Shirkey 2004-01-05 16:13 ` DMIX and capture stream David Lloyd 1 sibling, 2 replies; 41+ messages in thread From: Patrick Shirkey @ 2004-01-05 6:00 UTC (permalink / raw) To: David Lloyd; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* HDSP as normal user. 2004-01-05 6:00 ` Patrick Shirkey @ 2004-01-05 10:18 ` Patrick Shirkey 2004-01-05 14:02 ` Paul Davis 2004-01-05 14:22 ` Takashi Iwai 2004-01-05 16:13 ` DMIX and capture stream David Lloyd 1 sibling, 2 replies; 41+ messages in thread From: Patrick Shirkey @ 2004-01-05 10:18 UTC (permalink / raw) Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: HDSP as normal user. 2004-01-05 10:18 ` HDSP as normal user Patrick Shirkey @ 2004-01-05 14:02 ` Paul Davis 2004-01-05 14:22 ` Takashi Iwai 1 sibling, 0 replies; 41+ messages in thread From: Paul Davis @ 2004-01-05 14:02 UTC (permalink / raw) To: Patrick Shirkey; +Cc: alsa-devel >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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: HDSP as normal user. 2004-01-05 10:18 ` HDSP as normal user Patrick Shirkey 2004-01-05 14:02 ` Paul Davis @ 2004-01-05 14:22 ` Takashi Iwai 2004-01-05 14:48 ` Patrick Shirkey 1 sibling, 1 reply; 41+ messages in thread From: Takashi Iwai @ 2004-01-05 14:22 UTC (permalink / raw) To: Patrick Shirkey; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: HDSP as normal user. 2004-01-05 14:22 ` Takashi Iwai @ 2004-01-05 14:48 ` Patrick Shirkey 0 siblings, 0 replies; 41+ messages in thread From: Patrick Shirkey @ 2004-01-05 14:48 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 6:00 ` Patrick Shirkey 2004-01-05 10:18 ` HDSP as normal user Patrick Shirkey @ 2004-01-05 16:13 ` David Lloyd 2004-01-05 16:21 ` Jaroslav Kysela 1 sibling, 1 reply; 41+ messages in thread From: David Lloyd @ 2004-01-05 16:13 UTC (permalink / raw) To: Patrick Shirkey; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 16:13 ` DMIX and capture stream David Lloyd @ 2004-01-05 16:21 ` Jaroslav Kysela 0 siblings, 0 replies; 41+ messages in thread From: Jaroslav Kysela @ 2004-01-05 16:21 UTC (permalink / raw) To: David Lloyd; +Cc: Patrick Shirkey, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-04 5:07 ` Paul Davis 2004-01-04 12:12 ` Joern Nettingsmeier 2004-01-04 13:52 ` Florian Schmidt @ 2004-01-05 16:29 ` David Lloyd 2004-01-05 16:28 ` Jaroslav Kysela 2004-01-05 16:42 ` Takashi Iwai 2 siblings, 2 replies; 41+ messages in thread From: David Lloyd @ 2004-01-05 16:29 UTC (permalink / raw) To: Paul Davis; +Cc: ALSA Mailing List 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 16:29 ` David Lloyd @ 2004-01-05 16:28 ` Jaroslav Kysela 2004-01-05 16:43 ` Takashi Iwai ` (2 more replies) 2004-01-05 16:42 ` Takashi Iwai 1 sibling, 3 replies; 41+ messages in thread From: Jaroslav Kysela @ 2004-01-05 16:28 UTC (permalink / raw) To: David Lloyd; +Cc: ALSA Mailing List 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 16:28 ` Jaroslav Kysela @ 2004-01-05 16:43 ` Takashi Iwai 2004-01-05 17:27 ` David Lloyd 2004-01-05 17:28 ` Florian Schmidt 2 siblings, 0 replies; 41+ messages in thread From: Takashi Iwai @ 2004-01-05 16:43 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: David Lloyd, ALSA Mailing List 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 16:28 ` Jaroslav Kysela 2004-01-05 16:43 ` Takashi Iwai @ 2004-01-05 17:27 ` David Lloyd 2004-01-05 17:28 ` Florian Schmidt 2 siblings, 0 replies; 41+ messages in thread From: David Lloyd @ 2004-01-05 17:27 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: ALSA Mailing List 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 16:28 ` Jaroslav Kysela 2004-01-05 16:43 ` Takashi Iwai 2004-01-05 17:27 ` David Lloyd @ 2004-01-05 17:28 ` Florian Schmidt 2 siblings, 0 replies; 41+ messages in thread From: Florian Schmidt @ 2004-01-05 17:28 UTC (permalink / raw) To: Jaroslav Kysela; +Cc: dmlloyd, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 16:29 ` David Lloyd 2004-01-05 16:28 ` Jaroslav Kysela @ 2004-01-05 16:42 ` Takashi Iwai 2004-01-05 17:20 ` David Lloyd 1 sibling, 1 reply; 41+ messages in thread From: Takashi Iwai @ 2004-01-05 16:42 UTC (permalink / raw) To: David Lloyd; +Cc: Paul Davis, ALSA Mailing List 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 16:42 ` Takashi Iwai @ 2004-01-05 17:20 ` David Lloyd 2004-01-05 17:41 ` Paul Davis 0 siblings, 1 reply; 41+ messages in thread From: David Lloyd @ 2004-01-05 17:20 UTC (permalink / raw) To: Takashi Iwai; +Cc: Paul Davis, ALSA Mailing List 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 17:20 ` David Lloyd @ 2004-01-05 17:41 ` Paul Davis 2004-01-05 17:45 ` David Lloyd 2004-01-05 18:12 ` Takashi Iwai 0 siblings, 2 replies; 41+ messages in thread From: Paul Davis @ 2004-01-05 17:41 UTC (permalink / raw) To: David Lloyd; +Cc: Takashi Iwai, ALSA Mailing List >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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 17:41 ` Paul Davis @ 2004-01-05 17:45 ` David Lloyd 2004-01-05 18:59 ` Paul Davis 2004-01-05 18:12 ` Takashi Iwai 1 sibling, 1 reply; 41+ messages in thread From: David Lloyd @ 2004-01-05 17:45 UTC (permalink / raw) To: Paul Davis; +Cc: Takashi Iwai, ALSA Mailing List 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 17:45 ` David Lloyd @ 2004-01-05 18:59 ` Paul Davis 0 siblings, 0 replies; 41+ messages in thread From: Paul Davis @ 2004-01-05 18:59 UTC (permalink / raw) To: David Lloyd; +Cc: Takashi Iwai, ALSA Mailing List >> >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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 17:41 ` Paul Davis 2004-01-05 17:45 ` David Lloyd @ 2004-01-05 18:12 ` Takashi Iwai 2004-01-06 17:05 ` David Lloyd 1 sibling, 1 reply; 41+ messages in thread From: Takashi Iwai @ 2004-01-05 18:12 UTC (permalink / raw) To: Paul Davis; +Cc: David Lloyd, ALSA Mailing List [-- 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; ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-05 18:12 ` Takashi Iwai @ 2004-01-06 17:05 ` David Lloyd 2004-01-06 21:38 ` Florian Schmidt 0 siblings, 1 reply; 41+ messages in thread From: David Lloyd @ 2004-01-06 17:05 UTC (permalink / raw) To: Takashi Iwai; +Cc: Paul Davis, ALSA Mailing List 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-06 17:05 ` David Lloyd @ 2004-01-06 21:38 ` Florian Schmidt 2004-01-07 11:01 ` Takashi Iwai 0 siblings, 1 reply; 41+ messages in thread From: Florian Schmidt @ 2004-01-06 21:38 UTC (permalink / raw) To: alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-06 21:38 ` Florian Schmidt @ 2004-01-07 11:01 ` Takashi Iwai 2004-01-07 12:05 ` Florian Schmidt 2004-01-07 12:45 ` Abramo Bagnara 0 siblings, 2 replies; 41+ messages in thread From: Takashi Iwai @ 2004-01-07 11:01 UTC (permalink / raw) To: Florian Schmidt; +Cc: alsa-devel [-- 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 11:01 ` Takashi Iwai @ 2004-01-07 12:05 ` Florian Schmidt 2004-01-07 13:06 ` Florian Schmidt 2004-01-07 12:45 ` Abramo Bagnara 1 sibling, 1 reply; 41+ messages in thread From: Florian Schmidt @ 2004-01-07 12:05 UTC (permalink / raw) To: Takashi Iwai; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 12:05 ` Florian Schmidt @ 2004-01-07 13:06 ` Florian Schmidt 2004-01-07 13:49 ` Takashi Iwai 0 siblings, 1 reply; 41+ messages in thread From: Florian Schmidt @ 2004-01-07 13:06 UTC (permalink / raw) To: Florian Schmidt; +Cc: tiwai, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 13:06 ` Florian Schmidt @ 2004-01-07 13:49 ` Takashi Iwai 0 siblings, 0 replies; 41+ messages in thread From: Takashi Iwai @ 2004-01-07 13:49 UTC (permalink / raw) To: Florian Schmidt; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 11:01 ` Takashi Iwai 2004-01-07 12:05 ` Florian Schmidt @ 2004-01-07 12:45 ` Abramo Bagnara 2004-01-07 13:45 ` Takashi Iwai 1 sibling, 1 reply; 41+ messages in thread From: Abramo Bagnara @ 2004-01-07 12:45 UTC (permalink / raw) To: Takashi Iwai; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 12:45 ` Abramo Bagnara @ 2004-01-07 13:45 ` Takashi Iwai 2004-01-07 14:39 ` Abramo Bagnara 0 siblings, 1 reply; 41+ messages in thread From: Takashi Iwai @ 2004-01-07 13:45 UTC (permalink / raw) To: Abramo Bagnara; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 13:45 ` Takashi Iwai @ 2004-01-07 14:39 ` Abramo Bagnara 2004-01-07 15:02 ` Takashi Iwai 0 siblings, 1 reply; 41+ messages in thread From: Abramo Bagnara @ 2004-01-07 14:39 UTC (permalink / raw) To: Takashi Iwai; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 14:39 ` Abramo Bagnara @ 2004-01-07 15:02 ` Takashi Iwai 2004-01-07 15:15 ` Abramo Bagnara 2004-01-08 8:33 ` Jaroslav Kysela 0 siblings, 2 replies; 41+ messages in thread From: Takashi Iwai @ 2004-01-07 15:02 UTC (permalink / raw) To: Abramo Bagnara; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 15:02 ` Takashi Iwai @ 2004-01-07 15:15 ` Abramo Bagnara 2004-01-07 15:30 ` Takashi Iwai 2004-01-08 8:33 ` Jaroslav Kysela 1 sibling, 1 reply; 41+ messages in thread From: Abramo Bagnara @ 2004-01-07 15:15 UTC (permalink / raw) To: Takashi Iwai; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 15:15 ` Abramo Bagnara @ 2004-01-07 15:30 ` Takashi Iwai 2004-01-07 15:47 ` Abramo Bagnara 0 siblings, 1 reply; 41+ messages in thread From: Takashi Iwai @ 2004-01-07 15:30 UTC (permalink / raw) To: Abramo Bagnara; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 15:30 ` Takashi Iwai @ 2004-01-07 15:47 ` Abramo Bagnara 2004-01-07 16:12 ` Takashi Iwai 0 siblings, 1 reply; 41+ messages in thread From: Abramo Bagnara @ 2004-01-07 15:47 UTC (permalink / raw) To: Takashi Iwai; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 15:47 ` Abramo Bagnara @ 2004-01-07 16:12 ` Takashi Iwai 2004-01-07 16:58 ` Abramo Bagnara 0 siblings, 1 reply; 41+ messages in thread From: Takashi Iwai @ 2004-01-07 16:12 UTC (permalink / raw) To: Abramo Bagnara; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 16:12 ` Takashi Iwai @ 2004-01-07 16:58 ` Abramo Bagnara 2004-01-07 17:22 ` Takashi Iwai 0 siblings, 1 reply; 41+ messages in thread From: Abramo Bagnara @ 2004-01-07 16:58 UTC (permalink / raw) To: Takashi Iwai; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 16:58 ` Abramo Bagnara @ 2004-01-07 17:22 ` Takashi Iwai 0 siblings, 0 replies; 41+ messages in thread From: Takashi Iwai @ 2004-01-07 17:22 UTC (permalink / raw) To: Abramo Bagnara; +Cc: Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
* Re: DMIX and capture stream 2004-01-07 15:02 ` Takashi Iwai 2004-01-07 15:15 ` Abramo Bagnara @ 2004-01-08 8:33 ` Jaroslav Kysela 1 sibling, 0 replies; 41+ messages in thread From: Jaroslav Kysela @ 2004-01-08 8:33 UTC (permalink / raw) To: Takashi Iwai; +Cc: Abramo Bagnara, Florian Schmidt, alsa-devel 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 ^ permalink raw reply [flat|nested] 41+ messages in thread
end of thread, other threads:[~2004-01-08 8:33 UTC | newest] Thread overview: 41+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-02 20:29 DMIX and capture stream David Lloyd 2004-01-04 5:07 ` Paul Davis 2004-01-04 12:12 ` Joern Nettingsmeier 2004-01-04 13:52 ` Florian Schmidt 2004-01-05 0:02 ` David Lloyd 2004-01-05 0:15 ` Florian Schmidt 2004-01-05 6:00 ` Patrick Shirkey 2004-01-05 10:18 ` HDSP as normal user Patrick Shirkey 2004-01-05 14:02 ` Paul Davis 2004-01-05 14:22 ` Takashi Iwai 2004-01-05 14:48 ` Patrick Shirkey 2004-01-05 16:13 ` DMIX and capture stream David Lloyd 2004-01-05 16:21 ` Jaroslav Kysela 2004-01-05 16:29 ` David Lloyd 2004-01-05 16:28 ` Jaroslav Kysela 2004-01-05 16:43 ` Takashi Iwai 2004-01-05 17:27 ` David Lloyd 2004-01-05 17:28 ` Florian Schmidt 2004-01-05 16:42 ` Takashi Iwai 2004-01-05 17:20 ` David Lloyd 2004-01-05 17:41 ` Paul Davis 2004-01-05 17:45 ` David Lloyd 2004-01-05 18:59 ` Paul Davis 2004-01-05 18:12 ` Takashi Iwai 2004-01-06 17:05 ` David Lloyd 2004-01-06 21:38 ` Florian Schmidt 2004-01-07 11:01 ` Takashi Iwai 2004-01-07 12:05 ` Florian Schmidt 2004-01-07 13:06 ` Florian Schmidt 2004-01-07 13:49 ` Takashi Iwai 2004-01-07 12:45 ` Abramo Bagnara 2004-01-07 13:45 ` Takashi Iwai 2004-01-07 14:39 ` Abramo Bagnara 2004-01-07 15:02 ` Takashi Iwai 2004-01-07 15:15 ` Abramo Bagnara 2004-01-07 15:30 ` Takashi Iwai 2004-01-07 15:47 ` Abramo Bagnara 2004-01-07 16:12 ` Takashi Iwai 2004-01-07 16:58 ` Abramo Bagnara 2004-01-07 17:22 ` Takashi Iwai 2004-01-08 8:33 ` Jaroslav Kysela
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.