Build-in mixer

Build-in mixer

[Dan Tihelka]

Hallo every great ALSA developers,



I have one question. Is audio stream mixer planned or build in in ALSA, 
to be able to use different programs with audio output together? Like a 
case when i'm playing a movie (e.g. via mplayer with ALSA support) and i 
really want to listen an ICQ or  mail confirmation sounds (because i'm 
expecting wery important message).

I don't know, if the term "mixer" is used correctly, because i am not 
expert on it. I have in mind to use ALSA by more than one programs at 
the same time (simultaneously), and ALSA itself should mix these audio 
streams to one and play it via soundcard.


I tried dmix plug-in together with aplay -Dplug:dmix simultaneously from 
  two consoles and it works sufficiently (well, "underun!!! (at least 
...ms long)" message was there but i don't know, if is is serious bug or 
not). I thing that it should work transparently without special swithes 
or settings separately for each application or its instance, but i don't 
know if it is possible or not.


If some cards are able to do it by their hardware (are there such 
cards?) the mixer would not be used, in other cases it should be used 
automatically, and ALSA knows if to use it or not according to used 
sound card. Then ALSA would be KDE/Gnome/and_others independent and all 
applications supporting it (or supporting OSS) would be able to play 
simultaneously.


I wish you a lot of sucessful work,

Dan










-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Build-in mixer

[Paul Davis]

>I don't know, if the term "mixer" is used correctly, because i am not 
>expert on it. I have in mind to use ALSA by more than one programs at 
>the same time (simultaneously), and ALSA itself should mix these audio 
>streams to one and play it via soundcard.

just so you know, although this functionality is certain desired by
many, its not the way that some users want things to work. as a
result, ALSA makes this possible, but it doesn't do it by default. Put
another way, it provides a mechanism to do this, but doesn't enforce
it as a policy.

>I tried dmix plug-in together with aplay -Dplug:dmix simultaneously from 
>  two consoles and it works sufficiently (well, "underun!!! (at least 
>...ms long)" message was there but i don't know, if is is serious bug or 
>not). I thing that it should work transparently without special swithes 
>or settings separately for each application or its instance, but i don't 
>know if it is possible or not.

the dmix plugin is indeed the way to do this. what you need to do (or
perhaps ALSA needs to by default) is to set up your ~/.asoundrc so
that the default device is a dmix configuration.

all ALSA applications should accept options from the user specifying
which PCM (or MIDI or ...) device they should open, and they fall back
to "default" if none is specified. consequently, with this
configuration setup, you'd get what you are hoping for, but other
people could still use "hw:1" or specific named devices when they
don't want dmix to get in the way (e.g. professional audio users).

unfortunately, i don't know how to write an ~/.asoundrc file that
would do that :( somebody will, though.

--p


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Build-in mixer

[Takashi Iwai]

At Wed, 08 Oct 2003 07:24:16 -0400,
Paul Davis wrote:
> 
> >I don't know, if the term "mixer" is used correctly, because i am not 
> >expert on it. I have in mind to use ALSA by more than one programs at 
> >the same time (simultaneously), and ALSA itself should mix these audio 
> >streams to one and play it via soundcard.
> 
> just so you know, although this functionality is certain desired by
> many, its not the way that some users want things to work. as a
> result, ALSA makes this possible, but it doesn't do it by default. Put
> another way, it provides a mechanism to do this, but doesn't enforce
> it as a policy.
> 
> >I tried dmix plug-in together with aplay -Dplug:dmix simultaneously from 
> >  two consoles and it works sufficiently (well, "underun!!! (at least 
> >...ms long)" message was there but i don't know, if is is serious bug or 
> >not). I thing that it should work transparently without special swithes 
> >or settings separately for each application or its instance, but i don't 
> >know if it is possible or not.
> 
> the dmix plugin is indeed the way to do this. what you need to do (or
> perhaps ALSA needs to by default) is to set up your ~/.asoundrc so
> that the default device is a dmix configuration.
> 
> all ALSA applications should accept options from the user specifying
> which PCM (or MIDI or ...) device they should open, and they fall back
> to "default" if none is specified. consequently, with this
> configuration setup, you'd get what you are hoping for, but other
> people could still use "hw:1" or specific named devices when they
> don't want dmix to get in the way (e.g. professional audio users).
> 
> unfortunately, i don't know how to write an ~/.asoundrc file that
> would do that :( somebody will, though.

it's becoming an FAQ... :)

pcm.!default {
	type plug
	slave.pcm "dmix"
}

the point is '!' prefix, which means overriding the existing
definition.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Build-in mixer

[Dan Tihelka]

Takashi Iwai wrote:

>it's becoming an FAQ... :)
>
>pcm.!default {
>	type plug
>	slave.pcm "dmix"
>}
>
>the point is '!' prefix, which means overriding the existing
>definition.
>
>
>Takashi
>

Great, it works. Thank You very much for your help.

But i have one other question. When i tried to play more sounds 
simultenaously (using aplay), the message :  "underrun!!! (at least 
....ms long)" occured. Is it OK?

Dan




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Daniel Tihelka]

Cituji z e-mailu od Takashi Iwai <tiwai@suse.de>:

> 
> it's becoming an FAQ... :)
> 
> pcm.!default {
> 	type plug
> 	slave.pcm "dmix"
> }
> 
> the point is '!' prefix, which means overriding the existing
> definition.
> 


As I wrote some day ago, it is possible to play two or more sounds 
simultenaously with mentioned setting. But only with 'aplay'

I tried to use xmms with ALSA 0.9 output plugin and Mplayer with ALSA-0.9.x 
support and it is impossible to play any two sound streams at the same time (i 
tried two xmms, xmms + mplayer, xmms + asound, mplayer + asound and two 
mplayers, but only the first played and the second was stopped until the first 
finished or breaked).

Where can be problem? Is it in the way, how ALSA device is opened? Must be 
device opened in a different way? Aad what about streams with different 
sampling frequencies? (I don't understand ALSA interface now, but I plan to 
learn it). 

Thank you very much,

Dan




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Frank Barknecht]

Hallo,
Daniel Tihelka hat gesagt: // Daniel Tihelka wrote:

> As I wrote some day ago, it is possible to play two or more sounds 
> simultenaously with mentioned setting. But only with 'aplay'
> 
> I tried to use xmms with ALSA 0.9 output plugin and Mplayer with ALSA-0.9.x 
> support and it is impossible to play any two sound streams at the same time (i 
> tried two xmms, xmms + mplayer, xmms + asound, mplayer + asound and two 
> mplayers, but only the first played and the second was stopped until the first 
> finished or breaked).
> 
> Where can be problem? 

The problem lies in the wrong way in which these apps try to use ALSA.
I don't use XMMS anymore, but for mplayer I can say, that it tries to
open hw:X devices and doesn't allow the user to specify a device by
name. As dmix goes beyond and extends the capabilites of the hardware
you're out of luck with these kind of apps unless the authors fix
their mistakes. For a correctly written ALSA music player try
alsaplayer. It works like a charm with dmix and since ALSA 0.9.7 it
does so even on my M-Audio Audiophile card btw.

You might have success with running these apps in OSS-mode and useing
alsa-oss.

ciao
-- 
 Frank Barknecht                               _ ______footils.org__


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Clemens Ladisch]

Daniel Tihelka wrote:
> [dmix]
> Aad what about streams with different sampling frequencies?

The dmix plugin always uses a fixed sample rate. The default is 48000,
but you can change it as follows:

pcm.!default {
	type plug
	slave.pcm {
		type dmix
		ipc_key 54042615
		ipc_key_add_uid yes
		slave {
			pcm "hw:0"
			rate 44100
		}
	}
}


HTH
Clemens




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Dan Tihelka]

Frank Barknecht wrote:

>>As I wrote some day ago, it is possible to play two or more sounds 
>>simultenaously with mentioned setting. But only with 'aplay'
>>
>>I tried to use xmms with ALSA 0.9 output plugin and Mplayer with ALSA-0.9.x 
>>support and it is impossible to play any two sound streams at the same time (i 
>>tried two xmms, xmms + mplayer, xmms + asound, mplayer + asound and two 
>>mplayers, but only the first played and the second was stopped until the first 
>>finished or breaked).
>>
>>Where can be problem? 
>>    
>>
>
>The problem lies in the wrong way in which these apps try to use ALSA.
>I don't use XMMS anymore, but for mplayer I can say, that it tries to
>open hw:X devices and doesn't allow the user to specify a device by
>name. 
>
I experimented with xmms ALSA output plugin and i forced "default" 
instead of "hw:0:0" to the audio opening command:

snd_pcm_open ( &handle, "default", SND_PCM_STREAM_PLAYBACK, 
SND_PCM_NONBLOCK );

but a error occured. I would like to ask you, if it is sufficient to 
change it only, or if there must be other changes when opening device? 
And why there is a possibility to force opening  mode by application, 
instead of offering interface which does not enable it and leave user to 
decide if to use mixer or not. Otherwise there is still possibility of 
 "forcing  ideas" by applications until they will be rewritten (if they 
will at all).


Thank you very much,

Dan




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Paul Davis]

>I experimented with xmms ALSA output plugin and i forced "default" 
>instead of "hw:0:0" to the audio opening command:
>
>snd_pcm_open ( &handle, "default", SND_PCM_STREAM_PLAYBACK, 
>SND_PCM_NONBLOCK );
>
>but a error occured. I would like to ask you, if it is sufficient to 

perhaps you know this, but 

	"an error occured"

is an extremely content-free way of describing a problem.

>change it only, or if there must be other changes when opening device? 

no other change is necessary. however, to do what you want, you have
to redefine the "default" device to be a dmix device. clemens
takashi posted within the last couple of days how to do this.


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Dan Tihelka]

Paul Davis wrote:

>perhaps you know this, but 
>
>	"an error occured"
>
>is an extremely content-free way of describing a problem.
>  
>
I am sorry. I know it. But i don't know, if it was error caused by ALSA. 
There is a part of code in audio.c in alsa-xmms-0.9 which probably 
caused the error (I add some printf there):

	if(alsa_cfg.debug)
	   printf("Starting to open device ....\n");

	if(alsa_cfg.use_user_device)
	{
	   if(alsa_cfg.debug) printf("Opening user device: --%s--\n", alsa_cfg.user_device);
	   if((err = snd_pcm_open(&alsa_pcm, alsa_cfg.user_device, SND_PCM_STREAM_PLAYBACK, SND_PCM_NONBLOCK)) < 0)
	       alsa_error("error opening alsa device: %s", err);
	}

	if(alsa_cfg.debug)
	   printf("Device opened\n");



and there is console output:

	Starting to open device ....
	Opening user device: --default--
	Xlib: unexpected async reply (sequence 0x963)!


I have no idea what kind of error it is.... But what it do, is to try open "default" device only, i suppose. And it should not caused problems, if I understand well:

>no other change is necessary. however, to do what you want, you have
>to redefine the "default" device to be a dmix device. clemens
>takashi posted within the last couple of days how to do this.
>  
>
My ~/.asoundrc file is:

	pcm.!default {
		type plug
		slave.pcm "dmix"
	}

And some lines behind #. It must be correct, because more than one 'aplay' play simultenaously (even though with "underrun!!! (...)" message).



I found other ALSA setting where hw: is used. It is called before snd_pcm_open() is called, and it looks like:

	void alsa_setup_mixer(void)
	{
        	debug("alsa_setup_mixer")

	        if(alsa_cfg.audio_card != 0)
        	   sprintf(card_id, "hw:%i", alsa_cfg.audio_card);
	

	        snd_mixer_open(&mixer, 0);
        	snd_mixer_attach(mixer, card_id);              // <------ there hw:0 is used
	        snd_mixer_selem_register(mixer, NULL, NULL);
	        snd_mixer_load (mixer);
        	snd_mixer_selem_id_malloc(&pcm_elt);

		...... and many others, i don't know, if it is important.



I found, that variable card_id is set to "hw:0" string. Is there anything else, what should i try? Because i really love to use dmix plug-in together with another applications :-)


Thank You very much,
Dan


P.S. Frank Barknecht suggested: "You might have success with running these apps in OSS-mode and useing
alsa-oss". I try it, but it only one program was able to use ALSA at the same time. 





-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Paul Davis]

>	Starting to open device ....
>	Opening user device: --default--
>	Xlib: unexpected async reply (sequence 0x963)!

your program uses threads, right? or it forks at some point? and your
alsa_error() function involves calls to GUI functions? this error is from
Xlib, it has nothing to do with ALSA. its caused by having multiple
threads/processes making GUI calls without user-space
synchronization. most toolkits recommend that you do not do this, and
instead use a single thread for all GUI calls. you also cannot share a
connection to an X server between two processes.

--p




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Dan Tihelka]

Paul Davis wrote:

>>	Starting to open device ....
>>	Opening user device: --default--
>>	Xlib: unexpected async reply (sequence 0x963)!
>>    
>>
>
>your program uses threads, right? or it forks at some point? and your
>alsa_error() function involves calls to GUI functions? this error is from
>Xlib, it has nothing to do with ALSA. its caused by having multiple
>threads/processes making GUI calls without user-space
>synchronization. most toolkits recommend that you do not do this, and
>instead use a single thread for all GUI calls. you also cannot share a
>connection to an X server between two processes.
>  
>
Well, i am not author of this program actually. It is xmms plugin 
allowing  to use ALSA for sound output (alsa-xmms-0.9). I only wanted to 
modify it, to be able to use dmix. I see, that it is out of my abilities 
:-(  and, so i will have to conctact the author of it and ask him to 
correct it. It is pitty, because it will take time (if they ever do it). 
I thought, that ALSA interface is not dependent on way, how it is opened 
(because the same code with "hw:0:0" instead of "default" worked 
perfectly) or did not i comprehend anything?. I would like to 
understant, why opening "hw:0:0" works and only replacing it by 
"default" does not. It seems to mee very dificult for developpers....

Thank you for all answers,

Dan




-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Paul Davis]

>Well, i am not author of this program actually. It is xmms plugin 
>allowing  to use ALSA for sound output (alsa-xmms-0.9). I only wanted to 
>modify it, to be able to use dmix. I see, that it is out of my abilities 
>:-(  and, so i will have to conctact the author of it and ask him to 
>correct it. It is pitty, because it will take time (if they ever do it). 
>I thought, that ALSA interface is not dependent on way, how it is opened 
>(because the same code with "hw:0:0" instead of "default" worked 
>perfectly) or did not i comprehend anything?. I would like to 
>understant, why opening "hw:0:0" works and only replacing it by 
>"default" does not. It seems to mee very dificult for developpers....

it would have helped enormously if you had stated that you were
talking about alsa-xmms up front. its a known and important piece of
code, and one that someone here is much more likely to fix than (sorry
to say) your own pet project.

takashi or jaroslav - does using dmix involve any threads? could the
alsa-xmms plugin be making calls to some xmms error code from a
non-GUI thread?


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Takashi Iwai]

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

At Wed, 15 Oct 2003 08:40:47 -0400,
Paul Davis wrote:
> 
> >Well, i am not author of this program actually. It is xmms plugin 
> >allowing  to use ALSA for sound output (alsa-xmms-0.9). I only wanted to 
> >modify it, to be able to use dmix. I see, that it is out of my abilities 
> >:-(  and, so i will have to conctact the author of it and ask him to 
> >correct it. It is pitty, because it will take time (if they ever do it). 
> >I thought, that ALSA interface is not dependent on way, how it is opened 
> >(because the same code with "hw:0:0" instead of "default" worked 
> >perfectly) or did not i comprehend anything?. I would like to 
> >understant, why opening "hw:0:0" works and only replacing it by 
> >"default" does not. It seems to mee very dificult for developpers....
> 
> it would have helped enormously if you had stated that you were
> talking about alsa-xmms up front. its a known and important piece of
> code, and one that someone here is much more likely to fix than (sorry
> to say) your own pet project.
> 
> takashi or jaroslav - does using dmix involve any threads? could the
> alsa-xmms plugin be making calls to some xmms error code from a
> non-GUI thread?

it's not related with threads, but it invokes a fork for a server
process (a main control only, doesn't do mixing stuffs).
it looks like there is something wrong with this together with xmms.
i've seen that Xlib got a spurious async.
magically enough, the attached patch seems to fix.

Jaroslav, what is the reason of the second fork?  to daemonize?

hmm, i still got many underruns.  something broken atm...


Takashi

[-- Attachment #2: pcm-dmix-fix.dif --]
[-- Type: application/octet-stream, Size: 665 bytes --]

Index: alsa-lib/src/pcm/pcm_direct.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-lib/src/pcm/pcm_direct.c,v
retrieving revision 1.5
diff -u -r1.5 pcm_direct.c
--- alsa-lib/src/pcm/pcm_direct.c	8 Sep 2003 11:23:46 -0000	1.5
+++ alsa-lib/src/pcm/pcm_direct.c	15 Oct 2003 14:03:00 -0000
@@ -313,12 +313,12 @@
 		close(dmix->server_fd);
 		return ret;
 	} else if (ret == 0) {
-		ret = fork();
-		if (ret == 0)
+		//ret = fork();
+		//if (ret == 0)
 			server_job(dmix);
 		exit(EXIT_SUCCESS);
 	} else {
-		waitpid(ret, NULL, 0);
+		//waitpid(ret, NULL, 0);
 	}
 	dmix->server_pid = ret;
 	dmix->server = 1;

Re: Build-in mixer

[Paul Davis]

>it's not related with threads, but it invokes a fork for a server
>process (a main control only, doesn't do mixing stuffs).
>it looks like there is something wrong with this together with xmms.
>i've seen that Xlib got a spurious async.
>magically enough, the attached patch seems to fix.

>From http://www.gtk.org/faq/#AEN477

----------------------------------------------------------------------
5.5. Why does this strange 'x io error' occur when I fork() in my GTK+ app?
Why does this strange 'x io error' occur when I fork() in my GTK+ app?

This is not really a GTK+ problem, and the problem is not related to
fork() either. If the 'x io error' occurs then you probably use the
exit() function in order to exit from the child process.

When GDK opens an X display, it creates a socket file descriptor. When
you use the exit() function, you implicitly close all the open file
descriptors, and the underlying X library really doesn't like this.

The right function to use here is _exit().

Erik Mouw contributed the following code example to illustrate
handling fork() and exit().
----------------------------------------------------------------------


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Takashi Iwai]

At Wed, 15 Oct 2003 10:53:51 -0400,
Paul Davis wrote:
> 
> >it's not related with threads, but it invokes a fork for a server
> >process (a main control only, doesn't do mixing stuffs).
> >it looks like there is something wrong with this together with xmms.
> >i've seen that Xlib got a spurious async.
> >magically enough, the attached patch seems to fix.
> 
> >From http://www.gtk.org/faq/#AEN477
> 
> ----------------------------------------------------------------------
> 5.5. Why does this strange 'x io error' occur when I fork() in my GTK+ app?
> Why does this strange 'x io error' occur when I fork() in my GTK+ app?
> 
> This is not really a GTK+ problem, and the problem is not related to
> fork() either. If the 'x io error' occurs then you probably use the
> exit() function in order to exit from the child process.
> 
> When GDK opens an X display, it creates a socket file descriptor. When
> you use the exit() function, you implicitly close all the open file
> descriptors, and the underlying X library really doesn't like this.
> 
> The right function to use here is _exit().

oh yeah, that's it.  replacing two exit() calls in pcm_direct.c with
_exit() fixes the problem indeed.
thanks for the info!

now i need to reread the old good unix text book... :)


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Takashi Iwai]

At Wed, 15 Oct 2003 17:01:07 +0200,
I wrote:
> 
> At Wed, 15 Oct 2003 10:53:51 -0400,
> Paul Davis wrote:
> > 
> > >it's not related with threads, but it invokes a fork for a server
> > >process (a main control only, doesn't do mixing stuffs).
> > >it looks like there is something wrong with this together with xmms.
> > >i've seen that Xlib got a spurious async.
> > >magically enough, the attached patch seems to fix.
> > 
> > >From http://www.gtk.org/faq/#AEN477
> > 
> > ----------------------------------------------------------------------
> > 5.5. Why does this strange 'x io error' occur when I fork() in my GTK+ app?
> > Why does this strange 'x io error' occur when I fork() in my GTK+ app?
> > 
> > This is not really a GTK+ problem, and the problem is not related to
> > fork() either. If the 'x io error' occurs then you probably use the
> > exit() function in order to exit from the child process.
> > 
> > When GDK opens an X display, it creates a socket file descriptor. When
> > you use the exit() function, you implicitly close all the open file
> > descriptors, and the underlying X library really doesn't like this.
> > 
> > The right function to use here is _exit().
> 
> oh yeah, that's it.  replacing two exit() calls in pcm_direct.c with
> _exit() fixes the problem indeed.

also, don't close() in the beginning of server_job().
but there should be better way to handle such a case.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Jaroslav Kysela]

On Wed, 15 Oct 2003, Paul Davis wrote:

> >Well, i am not author of this program actually. It is xmms plugin
> >allowing  to use ALSA for sound output (alsa-xmms-0.9). I only wanted to
> >modify it, to be able to use dmix. I see, that it is out of my abilities
> >:-(  and, so i will have to conctact the author of it and ask him to
> >correct it. It is pitty, because it will take time (if they ever do it).
> >I thought, that ALSA interface is not dependent on way, how it is opened
> >(because the same code with "hw:0:0" instead of "default" worked
> >perfectly) or did not i comprehend anything?. I would like to
> >understant, why opening "hw:0:0" works and only replacing it by
> >"default" does not. It seems to mee very dificult for developpers....
>
> it would have helped enormously if you had stated that you were
> talking about alsa-xmms up front. its a known and important piece of
> code, and one that someone here is much more likely to fix than (sorry
> to say) your own pet project.
>
> takashi or jaroslav - does using dmix involve any threads? could the
> alsa-xmms plugin be making calls to some xmms error code from a
> non-GUI thread?

The dmix plugin does not use any threads and should be thread safe.
I think that the xmms code does not conform to the ALSA API. For example,
the application MUST use snd_pcm_poll_descriptors_revents() to obtain
the real event from poll(). And so on...

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Jaroslav Kysela]

On Wed, 15 Oct 2003, Takashi Iwai wrote:

> At Wed, 15 Oct 2003 08:40:47 -0400,
> Paul Davis wrote:
> >
> > >Well, i am not author of this program actually. It is xmms plugin
> > >allowing  to use ALSA for sound output (alsa-xmms-0.9). I only wanted to
> > >modify it, to be able to use dmix. I see, that it is out of my abilities
> > >:-(  and, so i will have to conctact the author of it and ask him to
> > >correct it. It is pitty, because it will take time (if they ever do it).
> > >I thought, that ALSA interface is not dependent on way, how it is opened
> > >(because the same code with "hw:0:0" instead of "default" worked
> > >perfectly) or did not i comprehend anything?. I would like to
> > >understant, why opening "hw:0:0" works and only replacing it by
> > >"default" does not. It seems to mee very dificult for developpers....
> >
> > it would have helped enormously if you had stated that you were
> > talking about alsa-xmms up front. its a known and important piece of
> > code, and one that someone here is much more likely to fix than (sorry
> > to say) your own pet project.
> >
> > takashi or jaroslav - does using dmix involve any threads? could the
> > alsa-xmms plugin be making calls to some xmms error code from a
> > non-GUI thread?
>
> it's not related with threads, but it invokes a fork for a server
> process (a main control only, doesn't do mixing stuffs).
> it looks like there is something wrong with this together with xmms.
> i've seen that Xlib got a spurious async.
> magically enough, the attached patch seems to fix.
>
> Jaroslav, what is the reason of the second fork?  to daemonize?

Yes, we need completely to detach from parent.

> hmm, i still got many underruns.  something broken atm...

I will look on this. Sorry, I was not available for two days.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Jaroslav Kysela]

On Wed, 15 Oct 2003, Takashi Iwai wrote:

> At Wed, 15 Oct 2003 10:53:51 -0400,
> Paul Davis wrote:
> >
> > >it's not related with threads, but it invokes a fork for a server
> > >process (a main control only, doesn't do mixing stuffs).
> > >it looks like there is something wrong with this together with xmms.
> > >i've seen that Xlib got a spurious async.
> > >magically enough, the attached patch seems to fix.
> >
> > >From http://www.gtk.org/faq/#AEN477
> >
> > ----------------------------------------------------------------------
> > 5.5. Why does this strange 'x io error' occur when I fork() in my GTK+ app?
> > Why does this strange 'x io error' occur when I fork() in my GTK+ app?
> >
> > This is not really a GTK+ problem, and the problem is not related to
> > fork() either. If the 'x io error' occurs then you probably use the
> > exit() function in order to exit from the child process.
> >
> > When GDK opens an X display, it creates a socket file descriptor. When
> > you use the exit() function, you implicitly close all the open file
> > descriptors, and the underlying X library really doesn't like this.
> >
> > The right function to use here is _exit().
>
> oh yeah, that's it.  replacing two exit() calls in pcm_direct.c with
> _exit() fixes the problem indeed.
> thanks for the info!

I think that only one replacement makes sense - in
snd_pcm_direct_server_create(). Fixed in CVS now.

BTW: An user already reported that _exit() should be used, but he didn't
explain the reason, so I posponed the change to see, if it's really
necessary.

						Jaroslav

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


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php

Re: Build-in mixer

[Takashi Iwai]

At Fri, 17 Oct 2003 09:41:27 +0200 (CEST),
Jaroslav wrote:
> 
> On Wed, 15 Oct 2003, Takashi Iwai wrote:
> 
> > At Wed, 15 Oct 2003 10:53:51 -0400,
> > Paul Davis wrote:
> > >
> > > >it's not related with threads, but it invokes a fork for a server
> > > >process (a main control only, doesn't do mixing stuffs).
> > > >it looks like there is something wrong with this together with xmms.
> > > >i've seen that Xlib got a spurious async.
> > > >magically enough, the attached patch seems to fix.
> > >
> > > >From http://www.gtk.org/faq/#AEN477
> > >
> > > ----------------------------------------------------------------------
> > > 5.5. Why does this strange 'x io error' occur when I fork() in my GTK+ app?
> > > Why does this strange 'x io error' occur when I fork() in my GTK+ app?
> > >
> > > This is not really a GTK+ problem, and the problem is not related to
> > > fork() either. If the 'x io error' occurs then you probably use the
> > > exit() function in order to exit from the child process.
> > >
> > > When GDK opens an X display, it creates a socket file descriptor. When
> > > you use the exit() function, you implicitly close all the open file
> > > descriptors, and the underlying X library really doesn't like this.
> > >
> > > The right function to use here is _exit().
> >
> > oh yeah, that's it.  replacing two exit() calls in pcm_direct.c with
> > _exit() fixes the problem indeed.
> > thanks for the info!
> 
> I think that only one replacement makes sense - in
> snd_pcm_direct_server_create(). Fixed in CVS now.

hmm, it looks like server_job() needs _exit(), too.
i got an error
	Gdk-ERROR **: Fatal IO error 9 (Bad file descriptor) on X server :0.0.
when i stop the playback with xmms-alsa.
replacing exit() with _exit() fixes the error.


Takashi


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php