Re: Why do I get broken pipe on write to a pcm in state PREPARED?

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Anders Torger]

On Wednesday 11 September 2002 21.08, you wrote:
> On Wed, 11 Sep 2002, Anders Torger wrote:
> > On Wednesday 11 September 2002 20.48, you wrote:
> > > On Wed, 11 Sep 2002, Anders Torger wrote:
> > > > I use a RME9652 hammerfall with two periods (the hardware is
> > > > that way).
> > > >
> > > > I watch a file descriptor associated to the output with
> > > > select(), when it gets ready for writing, I write data to the
> > > > pcm with snd_pcm_writen(). In the beginning, the state of the
> > > > pcm is PREPARED.
> > > >
> > > > What I would expect then, is that the file descriptor is ready
> > > > for writing until the two periods has been filled with data,
> > > > and then select will block (output buffers full, sound card not
> > > > running). But instead, when the two periods is filled with
> > > > data, select() still returns and says that the file descriptor
> > > > is ready for writing, but when calling snd_pcm_writen(), it
> > > > returns -EPIPE. The pcm state is still PREPARED.
> > > >
> > > > What is wrong? Is it me (probably), or is it alsa?
> > >
> > > You should also check for POLLERR. I'm not sure, that it's
> > > necessary to return POLLOUT together with POLLERR in that case.
> > > Anyway, application should check for POLLERR at first and then
> > > write data.
> >
> > I'm sorry, I don't understand, what would be the error in the above
> > case? I just want to watch the file descriptor for writing, and
> > expect that it will be triggered when there is available space in
> > the output buffer to write to, or, if there is an error, for
> > example broken pipe. But how could it be broken pipe if the pcm is
> > in state PREPARED? It has never been put into RUNNING.
> >
> > The problem here is that the output buffer is full, the pcm is not
> > RUNNING, but the file descriptor gets triggered anyway. When can
> > that happen?
>
> Please, understand this error as: We have no more room in the ring
> buffer, start the playback stream or discard samples. The kernel
> driver cannot do anything at this point (except that application
> waiting for fd will be stoped - it's not so nice if there is no other
> poll source).

Ok.

However, in my case, the starting of the sound card is made from 
another thread (or process actually), so the implementation would be 
greatly simplified if the file descriptor would just block, since then 
the software then does not need to know anything about the size of the 
output buffer and does not need to make adaptions for that.

Is it possible to adjust a stop threshold or something to get my 
desired behaviour?

/Anders Torger




-------------------------------------------------------
In remembrance
www.osdn.com/911/

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Paul Davis]

>Is it possible to adjust a stop threshold or something to get my 
>desired behaviour?

i think you should have set the start mode to START_DATA and the start
threshold appropriately. then the device would have started as soon as
the buffer was full.

--p



-------------------------------------------------------
In remembrance
www.osdn.com/911/

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Takashi Iwai]

At Wed, 11 Sep 2002 16:14:19 -0400,
Paul Davis wrote:
> 
> >Is it possible to adjust a stop threshold or something to get my 
> >desired behaviour?
> 
> i think you should have set the start mode to START_DATA and the start
> threshold appropriately. then the device would have started as soon as
> the buffer was full.

but this will make the driver to start the stream automatically.
if you want to start explicitly by yourself, then it's not a
concrete solution.


the question is the behavior at the following situation:
you are trying to write data greater than buffer size.  the device is
set up as blocking mode.  how does write() behave?

if the stream is running, it's blocked.  ok, fine.
meanwhile, on the current implementation, if the stream is prepared or
paused, it returns -EPIPE.

this is correct in a certain perspective:  the file is not writable,
and unless you change its state, data will be _never_ written.
blocking the operation makes no sense, hence the driver returns an
error.  this argument is valid on a single thread program.

however, if the program is multi-threaded the state can be changed in
other thread, then the operation may start in background.
hence, the driver should block.  this is the case we faced now.


the behavior of poll() is dependent on the behavior of write().
thus, in the former case, poll() should return POLLERR, while in the
latter case it should block.


i myself prefer to block the operation.  it's more intuitive.
if you don't like blocking, then you can open it in the non-blocking
mode.  i don't see any other drawbacks.


anyway, i'd like to hear other opinions, too.


ciao,

Takashi


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

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Anders Torger]

On Thursday 12 September 2002 13.13, you wrote:
> At Wed, 11 Sep 2002 16:14:19 -0400,
>
> Paul Davis wrote:
> > >Is it possible to adjust a stop threshold or something to get my
> > >desired behaviour?
> >
> > i think you should have set the start mode to START_DATA and the
> > start threshold appropriately. then the device would have started
> > as soon as the buffer was full.
>
> but this will make the driver to start the stream automatically.
> if you want to start explicitly by yourself, then it's not a
> concrete solution.
>
>
> the question is the behavior at the following situation:
> you are trying to write data greater than buffer size.  the device is
> set up as blocking mode.  how does write() behave?
>
> if the stream is running, it's blocked.  ok, fine.
> meanwhile, on the current implementation, if the stream is prepared
> or paused, it returns -EPIPE.
>
> this is correct in a certain perspective:  the file is not writable,
> and unless you change its state, data will be _never_ written.
> blocking the operation makes no sense, hence the driver returns an
> error.  this argument is valid on a single thread program.

This is the same case with writing to pipes, and when there is no 
reader in the other end. What will happen then is that when the buggy 
program fills the buffer is that it blocks. I think most unix 
programmers intuitively would expect this behaviour also from alsa file 
descriptors.

As I see it, there is no function to this behaviour, just saying "your 
program does not work" through a broken pipe instead of a dead-lock. I 
even would say that for most programmers it would be simpler to find 
the bug if it dead-locked instead of a broken pipe, since most would 
associate the broken pipe to a buffer underflow and search for the 
wrong problem. At least I did (however, my program would not have 
dead-locked either, since it has multiple processes)

> however, if the program is multi-threaded the state can be changed in
> other thread, then the operation may start in background.
> hence, the driver should block.  this is the case we faced now.
>
>
> the behavior of poll() is dependent on the behavior of write().
> thus, in the former case, poll() should return POLLERR, while in the
> latter case it should block.
>
>
> i myself prefer to block the operation.  it's more intuitive.
> if you don't like blocking, then you can open it in the non-blocking
> mode.  i don't see any other drawbacks.
>
>
> anyway, i'd like to hear other opinions, too.

Well, I have the same opinion, I'd just like to give another example 
(actually the same all over again, but I want to make it obvious). For 
a socket or a pipe, if noone reads from the other end, it will block 
forever. Thus, a buggy program will dead-lock. I think this example 
fits logically the case of writing to the sound-card but no-one starts 
it. It should then block forever.

The problem I have is that I do not see the use of generating a broken 
pipe in this situation, the only scenario I can come up with is "oh, I 
got a broken pipe, I must have forgotten to start the pcm, so I do it 
and try writing again". But that scenario is highly unlikely to occur 
in a program, and if it does, I would call it bad programming.

For the blocking case, however, there is a use, that of having multiple 
threads (or forked processes). In my case I have a input thread and and 
output thread, and the sound-card is started from the input thread, 
after the output buffer has been readily filled with data. Not that it 
is hard to change my program to do like ALSA wants it, but I think the 
behaviour is wrong, it is not what one would expect.

/Anders Torger


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

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Takashi Iwai]

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

At Thu, 12 Sep 2002 13:48:56 +0200,
Anders Torger wrote:
> 
(...snipped the analogy of pipes...)
> 
> Well, I have the same opinion, I'd just like to give another example 
> (actually the same all over again, but I want to make it obvious). For 
> a socket or a pipe, if noone reads from the other end, it will block 
> forever. Thus, a buggy program will dead-lock. I think this example 
> fits logically the case of writing to the sound-card but no-one starts 
> it. It should then block forever.
 
agreed, although the alsa is already apart from the standard device
operations (unlike normal devices, alsa needs an explicit set-up
before read/write).


> The problem I have is that I do not see the use of generating a broken 
> pipe in this situation, the only scenario I can come up with is "oh, I 
> got a broken pipe, I must have forgotten to start the pcm, so I do it 
> and try writing again". But that scenario is highly unlikely to occur 
> in a program, and if it does, I would call it bad programming.
> 
> For the blocking case, however, there is a use, that of having multiple 
> threads (or forked processes). In my case I have a input thread and and 
> output thread, and the sound-card is started from the input thread, 
> after the output buffer has been readily filled with data. Not that it 
> is hard to change my program to do like ALSA wants it, but I think the 
> behaviour is wrong, it is not what one would expect.

we can see this problem from a different angle:  on the current
scheme, you cannot block writing if the stream is not running.
writing more in the prepare state will always return an error
immediately.

btw, the attached patch is a quick and untested hack to change the
behavior as you wish :)
please give a try.


ciao,

Takashi

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

Index: alsa-kernel/core/pcm_lib.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/core/pcm_lib.c,v
retrieving revision 1.19
diff -u -r1.19 pcm_lib.c
--- alsa-kernel/core/pcm_lib.c	12 Aug 2002 09:45:01 -0000	1.19
+++ alsa-kernel/core/pcm_lib.c	12 Sep 2002 11:26:57 -0000
@@ -1842,14 +1842,9 @@
 		if (runtime->sleep_min == 0 && runtime->status->state == SNDRV_PCM_STATE_RUNNING)
 			snd_pcm_update_hw_ptr(substream);
 		avail = snd_pcm_playback_avail(runtime);
-		if (runtime->status->state == SNDRV_PCM_STATE_PAUSED ||
-		    runtime->status->state == SNDRV_PCM_STATE_PREPARED) {
-			if (avail < runtime->xfer_align) {
-				err = -EPIPE;
-				goto _end_unlock;
-			}
-		} else if (((avail < runtime->control->avail_min && size > avail) ||
-			    (size >= runtime->xfer_align && avail < runtime->xfer_align))) {
+		if (((runtime->status->state == SNDRV_PCM_STATE_RUNNING &&
+		      avail < runtime->control->avail_min && size > avail) ||
+		     (size >= runtime->xfer_align && avail < runtime->xfer_align))) {
 			wait_queue_t wait;
 			enum { READY, SIGNALED, ERROR, SUSPENDED, EXPIRED } state;
 			if (nonblock) {
@@ -1860,32 +1855,38 @@
 			init_waitqueue_entry(&wait, current);
 			add_wait_queue(&runtime->sleep, &wait);
 			while (1) {
+				state = READY;
 				set_current_state(TASK_INTERRUPTIBLE);
 				if (signal_pending(current)) {
 					state = SIGNALED;
 					break;
 				}
 				spin_unlock_irq(&runtime->lock);
-				if (schedule_timeout(10 * HZ) == 0) {
-					spin_lock_irq(&runtime->lock);
-					state = runtime->status->state == SNDRV_PCM_STATE_SUSPENDED ? SUSPENDED : EXPIRED;
-					break;
-				}
+				if (schedule_timeout(10 * HZ) == 0)
+					state = EXPIRED;
 				spin_lock_irq(&runtime->lock);
 				switch (runtime->status->state) {
-				case SNDRV_PCM_STATE_XRUN:
-					state = ERROR;
-					goto _end_loop;
 				case SNDRV_PCM_STATE_SUSPENDED:
 					state = SUSPENDED;
 					goto _end_loop;
-				default:
-					break;
-				}
-				avail = snd_pcm_playback_avail(runtime);
-				if (avail >= runtime->control->avail_min) {
+				case SNDRV_PCM_STATE_PREPARED:
+				case SNDRV_PCM_STATE_PAUSED:
 					state = READY;
+					avail = snd_pcm_playback_avail(runtime);
+					if (avail >= runtime->xfer_align)
+						goto _end_loop;
 					break;
+				case SNDRV_PCM_STATE_RUNNING:
+					if (state != READY)
+						goto _end_loop;
+					avail = snd_pcm_playback_avail(runtime);
+					if (avail >= runtime->control->avail_min)
+						goto _end_loop;
+					break;
+				case SNDRV_PCM_STATE_XRUN:
+				default:
+					state = ERROR;
+					goto _end_loop;
 				}
 			}
 		       _end_loop:
Index: alsa-kernel/core/pcm_native.c
===================================================================
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/core/pcm_native.c,v
retrieving revision 1.22
diff -u -r1.22 pcm_native.c
--- alsa-kernel/core/pcm_native.c	26 Aug 2002 10:00:17 -0000	1.22
+++ alsa-kernel/core/pcm_native.c	12 Sep 2002 11:01:14 -0000
@@ -2437,11 +2437,13 @@
 		mask = 0;
 		break;
 	case SNDRV_PCM_STATE_PREPARED:
+	case SNDRV_PCM_STATE_PAUSED:
 		if (avail > 0) {
 			mask = POLLOUT | POLLWRNORM;
 			break;
 		}
-		/* Fall through */
+		mask = 0;
+		break;
 	default:
 		mask = POLLOUT | POLLWRNORM | POLLERR;
 		break;

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Anders Torger]

On Thursday 12 September 2002 17.56, you wrote:
> we can see this problem from a different angle:  on the current
> scheme, you cannot block writing if the stream is not running.
> writing more in the prepare state will always return an error
> immediately.

Did I mention that I use non-blocking I/O? Well, I do, so what I block 
on is select(). I don't think that changes much though.

Thanks for the patch by the way... I shall look into it later (now I 
need to fix some bugs, the runtime problems I have is due to bugs in my 
program I have detected now). If someone else on this list want to try 
it out, I'd be glad, since I'm currently quite busy to just get my 
things working.

/Anders Torger


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

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Tim Goetze]

Takashi Iwai wrote:

>btw, the attached patch is a quick and untested hack to change the
>behavior as you wish :)
>please give a try.

i've already worked around it, but i think we save future coders 
some work if we get this done right.

anyways, your patch doesn't break jackd (ice) and my homegrown alsa
lib (ice and awe, all memory-mapped) but OSS stops working: mpg123 is
silent and reports 0:00 elapsed when ^C-quitting. the pcm channel on
the awe sounds like its playing (induced noise) but otherwise it's
silent.

tim



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

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Jaroslav Kysela]

On Thu, 12 Sep 2002, Takashi Iwai wrote:

> At Thu, 12 Sep 2002 13:48:56 +0200,
> Anders Torger wrote:
> > 
> (...snipped the analogy of pipes...)
> > 
> > Well, I have the same opinion, I'd just like to give another example 
> > (actually the same all over again, but I want to make it obvious). For 
> > a socket or a pipe, if noone reads from the other end, it will block 
> > forever. Thus, a buggy program will dead-lock. I think this example 
> > fits logically the case of writing to the sound-card but no-one starts 
> > it. It should then block forever.
>  
> agreed, although the alsa is already apart from the standard device
> operations (unlike normal devices, alsa needs an explicit set-up
> before read/write).
> 
> 
> > The problem I have is that I do not see the use of generating a broken 
> > pipe in this situation, the only scenario I can come up with is "oh, I 
> > got a broken pipe, I must have forgotten to start the pcm, so I do it 
> > and try writing again". But that scenario is highly unlikely to occur 
> > in a program, and if it does, I would call it bad programming.
> > 
> > For the blocking case, however, there is a use, that of having multiple 
> > threads (or forked processes). In my case I have a input thread and and 
> > output thread, and the sound-card is started from the input thread, 
> > after the output buffer has been readily filled with data. Not that it 
> > is hard to change my program to do like ALSA wants it, but I think the 
> > behaviour is wrong, it is not what one would expect.
> 
> we can see this problem from a different angle:  on the current
> scheme, you cannot block writing if the stream is not running.
> writing more in the prepare state will always return an error
> immediately.
> 
> btw, the attached patch is a quick and untested hack to change the
> behavior as you wish :)
> please give a try.

I think that the current behaviour of write() is ok, the behaviour of
poll() might be "fixed". I see advantages for both. I would prefer to have
this configurable to satisfy multi-threaded applications. We can put a new
variable to sw_params.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



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

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Takashi Iwai]

At Fri, 13 Sep 2002 11:41:17 +0200 (CEST),
Jaroslav wrote:
> 
> On Thu, 12 Sep 2002, Takashi Iwai wrote:
> 
> > > The problem I have is that I do not see the use of generating a broken 
> > > pipe in this situation, the only scenario I can come up with is "oh, I 
> > > got a broken pipe, I must have forgotten to start the pcm, so I do it 
> > > and try writing again". But that scenario is highly unlikely to occur 
> > > in a program, and if it does, I would call it bad programming.
> > > 
> > > For the blocking case, however, there is a use, that of having multiple 
> > > threads (or forked processes). In my case I have a input thread and and 
> > > output thread, and the sound-card is started from the input thread, 
> > > after the output buffer has been readily filled with data. Not that it 
> > > is hard to change my program to do like ALSA wants it, but I think the 
> > > behaviour is wrong, it is not what one would expect.
> > 
> > we can see this problem from a different angle:  on the current
> > scheme, you cannot block writing if the stream is not running.
> > writing more in the prepare state will always return an error
> > immediately.
> > 
> > btw, the attached patch is a quick and untested hack to change the
> > behavior as you wish :)
> > please give a try.
> 
> I think that the current behaviour of write() is ok, the behaviour of
> poll() might be "fixed". I see advantages for both. I would prefer to have
> this configurable to satisfy multi-threaded applications. We can put a new
> variable to sw_params.

a new sw_params was what i thought of firstly, too.
but afterwars, i came to realize that changing this behavior according
to the blocking flag is more logical.

if it's on the blocking mode, the driver should block if it's possible
to do write in future _by any chance_.
if it's not on the blocking mode, the driver should return -EAGAIN.
and, the behavior of poll() depends on the behavior of write().
if it blocks, then poll blocks, too.

for me this sounds very simple and easy...


Takashi


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

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Tim Goetze]

Takashi Iwai wrote:

>if it's on the blocking mode, the driver should block if it's possible
>to do write in future _by any chance_.
>if it's not on the blocking mode, the driver should return -EAGAIN.
>and, the behavior of poll() depends on the behavior of write().
>if it blocks, then poll blocks, too.

sorry, i beg to differ. poll returning immediately with EAGAIN on a
nonblock fd doesn't make sense to me. 

you call poll because you want to block until a read/write possible
condition, and not to check if read/write is possible now -- you'd
call read()/write() instead.

that's the behaviour other linux fds (file, socket, fifo etc) show
when set to nonblock, and that's what i think one naturally expects.

tim



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

Re: Why do I get broken pipe on write to a pcm in state PREPARED?

[Takashi Iwai]

At Fri, 13 Sep 2002 13:45:24 +0200 (CEST),
Tim Goetze wrote:
> 
> Takashi Iwai wrote:
> 
> >if it's on the blocking mode, the driver should block if it's possible
> >to do write in future _by any chance_.
> >if it's not on the blocking mode, the driver should return -EAGAIN.
> >and, the behavior of poll() depends on the behavior of write().
> >if it blocks, then poll blocks, too.
> 
> sorry, i beg to differ. poll returning immediately with EAGAIN on a
> nonblock fd doesn't make sense to me. 
 
yes, poll should block until it's ready.
i meant that if we implement blocking write, poll should be
implemented to block, too, unlike the current implementation.
of course, poll should block regardless of blocking mode.

sorry for confusing.


Takashi


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Jaroslav Kysela wrote:
> 
> On Thu, 12 Sep 2002, Takashi Iwai wrote:
> 
> > At Thu, 12 Sep 2002 13:48:56 +0200,
> > Anders Torger wrote:
> > >
> > (...snipped the analogy of pipes...)
> > >
> > > Well, I have the same opinion, I'd just like to give another example
> > > (actually the same all over again, but I want to make it obvious). For
> > > a socket or a pipe, if noone reads from the other end, it will block
> > > forever. Thus, a buggy program will dead-lock. I think this example
> > > fits logically the case of writing to the sound-card but no-one starts
> > > it. It should then block forever.
> >
> > agreed, although the alsa is already apart from the standard device
> > operations (unlike normal devices, alsa needs an explicit set-up
> > before read/write).
> >
> >
> > > The problem I have is that I do not see the use of generating a broken
> > > pipe in this situation, the only scenario I can come up with is "oh, I
> > > got a broken pipe, I must have forgotten to start the pcm, so I do it
> > > and try writing again". But that scenario is highly unlikely to occur
> > > in a program, and if it does, I would call it bad programming.
> > >
> > > For the blocking case, however, there is a use, that of having multiple
> > > threads (or forked processes). In my case I have a input thread and and
> > > output thread, and the sound-card is started from the input thread,
> > > after the output buffer has been readily filled with data. Not that it
> > > is hard to change my program to do like ALSA wants it, but I think the
> > > behaviour is wrong, it is not what one would expect.
> >
> > we can see this problem from a different angle:  on the current
> > scheme, you cannot block writing if the stream is not running.
> > writing more in the prepare state will always return an error
> > immediately.
> >
> > btw, the attached patch is a quick and untested hack to change the
> > behavior as you wish :)
> > please give a try.
> 
> I think that the current behaviour of write() is ok, the behaviour of
> poll() might be "fixed". I see advantages for both. I would prefer to have
> this configurable to satisfy multi-threaded applications. We can put a new
> variable to sw_params.

Implementing that specific behaviour for poll I've paid most attention
to efficiency issues.

Consider that if you choose a differente behaviour for poll you're
forced to check for xruns (i.e. enter kernel space) just before *every*
poll!

Sincerely I think this is a stupid approach and I doubt that making it
conditional is a smarter idea.

I'm missing something? (I'm just back from vacations and I've read far
too much messages ;-)

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

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


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Takashi Iwai]

At Sun, 15 Sep 2002 19:56:59 +0200,
Abramo Bagnara wrote:
> 
> Jaroslav Kysela wrote:
> > 
> > I think that the current behaviour of write() is ok, the behaviour of
> > poll() might be "fixed". I see advantages for both. I would prefer to have
> > this configurable to satisfy multi-threaded applications. We can put a new
> > variable to sw_params.
> 
> Implementing that specific behaviour for poll I've paid most attention
> to efficiency issues.
> 
> Consider that if you choose a differente behaviour for poll you're
> forced to check for xruns (i.e. enter kernel space) just before *every*
> poll!

well, the origianl question was the behavior of poll at the prepare
(and pause) state, so the theme has nothing to do with xruns (it
cannot happen :)

the behavior of poll at other states should be as well as before.

> Sincerely I think this is a stupid approach and I doubt that making it
> conditional is a smarter idea.

agreed here.


ciao,

Takashi


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Tim Goetze]

Takashi Iwai wrote:

>At Sun, 15 Sep 2002 19:56:59 +0200,
>Abramo Bagnara wrote:
>> 
>> Jaroslav Kysela wrote:
>> > 
>> > I think that the current behaviour of write() is ok, the behaviour of
>> > poll() might be "fixed". I see advantages for both. I would prefer to have
>> > this configurable to satisfy multi-threaded applications. We can put a new
>> > variable to sw_params.
>> 
>> Implementing that specific behaviour for poll I've paid most attention
>> to efficiency issues.
>> 
>> Consider that if you choose a differente behaviour for poll you're
>> forced to check for xruns (i.e. enter kernel space) just before *every*
>> poll!
>
>well, the origianl question was the behavior of poll at the prepare
>(and pause) state, so the theme has nothing to do with xruns (it
>cannot happen :)
>
>the behavior of poll at other states should be as well as before.
>
>> Sincerely I think this is a stupid approach and I doubt that making it
>> conditional is a smarter idea.
>
>agreed here.

i can't say i understand precisely what you agree on here. what i see
is that so far every now and then somebody writes to this list puzzled
at how poll can return immediately from polling a pcm stream that is
not running.

if you don't think this behaviour is broken then *please* update the
documentation, and clearly state how and why the poll implementation
handles things like it does.

tim



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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Takashi Iwai]

At Mon, 16 Sep 2002 15:18:29 +0200 (CEST),
Tim Goetze wrote:
> 
> >> Sincerely I think this is a stupid approach and I doubt that making it
> >> conditional is a smarter idea.
> >
> >agreed here.

> i can't say i understand precisely what you agree on here.

agreed that making it conditional is not better idea.

> what i see is that so far every now and then somebody writes to this
> list puzzled at how poll can return immediately from polling a pcm
> stream that is not running.
> 
> if you don't think this behaviour is broken then *please* update the
> documentation, and clearly state how and why the poll implementation
> handles things like it does.

i believe it's mis-implementation.  should be fixed.


Takashi


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Takashi Iwai wrote:
> 
> At Sun, 15 Sep 2002 19:56:59 +0200,
> Abramo Bagnara wrote:
> >
> > Jaroslav Kysela wrote:
> > >
> > > I think that the current behaviour of write() is ok, the behaviour of
> > > poll() might be "fixed". I see advantages for both. I would prefer to have
> > > this configurable to satisfy multi-threaded applications. We can put a new
> > > variable to sw_params.
> >
> > Implementing that specific behaviour for poll I've paid most attention
> > to efficiency issues.
> >
> > Consider that if you choose a differente behaviour for poll you're
> > forced to check for xruns (i.e. enter kernel space) just before *every*
> > poll!
> 
> well, the origianl question was the behavior of poll at the prepare
> (and pause) state, so the theme has nothing to do with xruns (it
> cannot happen :)
> 
> the behavior of poll at other states should be as well as before.
> 

I think that the best behaviour is the current and it's also the
simplest to describe and to understand: poll/select never blocks when
there is nothing to wait.

... and in PREPARED state definitely there's nothing to wait from sound
card.

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

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


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Tim Goetze]

Abramo Bagnara wrote:

>Takashi Iwai wrote:
>> 
>> At Sun, 15 Sep 2002 19:56:59 +0200,
>> Abramo Bagnara wrote:
>> >
>> > Jaroslav Kysela wrote:
>> > >
>> > > I think that the current behaviour of write() is ok, the behaviour of
>> > > poll() might be "fixed". I see advantages for both. I would prefer to have
>> > > this configurable to satisfy multi-threaded applications. We can put a new
>> > > variable to sw_params.
>> >
>> > Implementing that specific behaviour for poll I've paid most attention
>> > to efficiency issues.
>> >
>> > Consider that if you choose a differente behaviour for poll you're
>> > forced to check for xruns (i.e. enter kernel space) just before *every*
>> > poll!
>> 
>> well, the origianl question was the behavior of poll at the prepare
>> (and pause) state, so the theme has nothing to do with xruns (it
>> cannot happen :)
>> 
>> the behavior of poll at other states should be as well as before.
>> 
>
>I think that the best behaviour is the current and it's also the
>simplest to describe and to understand: poll/select never blocks when
>there is nothing to wait.
>
>... and in PREPARED state definitely there's nothing to wait from sound
>card.

you know that linux supports multi-threading, don't you?

;) tim



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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Anders Torger]

On Monday 16 September 2002 21.31, you wrote:
> I think that the best behaviour is the current and it's also the
> simplest to describe and to understand: poll/select never blocks when
> there is nothing to wait.
>
> ... and in PREPARED state definitely there's nothing to wait from
> sound card.

I don't agree. To a beginner which has never seen a unix system before, 
this might be the case. For anyone that has programmed with file 
descriptors before, this behaviour appears broken, and is therefore 
harder to understand.

Also, as we have noted, there is no real use for the current behaviour 
(at least no-one has said what it is), while there is use for the 
proper work-as-all-other-file-descriptors behaviour.

* It behaves as programmers expect it to behave
* It simplifies multi-threaded programming

If you don't agree to the first, just make a poll of the following:

"If the sound card output buffer is full of data, and it is not 
running, what would happen if you poll that file descriptor for writing"

1) it will block, because it is not ready for writing
2) it would not block, because it would then block forever

and then 

"If you write to a non-blocking sound card output file descriptor, but 
the buffer is full, and the sound card is not running, what will then 
happen?"

1) it will return with errno set to EAGAIN, because it is not ready for 
   writing
2) it will return with errno set to EPIPE, because there is a buffer
   overflow

If you ask experienced programmers these questions, which has no prior 
knowledge to alsa or at least not this particular subject, I can assure 
you that the answers will be 1) on both questions. The current 
behaviour just seems broken.

It makes sense to block, there may be another thread, or even another 
process starting the sound card. And it makes sense to return EAGAIN 
when writing to a non-blocking socket when it is not ready to accept 
data.

You might be right that the current behaviour is easier to understand 
for a beginner, but what will the beginner then expect from all other 
file descriptors? It's just confusing. I think it is wise to try to 
stick with established behaviour when possible, and only invent some 
own when necessary. In this case, the own behaviour does not even have 
any real function.

In conclusion, I advice you to change the behaviour to what we as 
programmers expect, and sometimes program for. I would very much 
appriciate it, and I'm sure others will as well

/Anders Torger


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Anders Torger wrote:
> 
> On Monday 16 September 2002 21.31, you wrote:
> > I think that the best behaviour is the current and it's also the
> > simplest to describe and to understand: poll/select never blocks when
> > there is nothing to wait.
> >
> > ... and in PREPARED state definitely there's nothing to wait from
> > sound card.
> 
> I don't agree. To a beginner which has never seen a unix system before,
> this might be the case. For anyone that has programmed with file
> descriptors before, this behaviour appears broken, and is therefore
> harder to understand.
> 
> Also, as we have noted, there is no real use for the current behaviour
> (at least no-one has said what it is), while there is use for the
> proper work-as-all-other-file-descriptors behaviour.
> 
> * It behaves as programmers expect it to behave
> * It simplifies multi-threaded programming

Please use technical argumentations: pseudo statistical and subjective
ones does not worth a lot.

> "If the sound card output buffer is full of data, and it is not
> running, what would happen if you poll that file descriptor for writing"
> 
> 1) it will block, because it is not ready for writing
> 2) it would not block, because it would then block forever

2 is better because the programmer can know the reason of failure.
With 1 the programmer will not receive enough info to detect it (also
using a timeout)

> "If you write to a non-blocking sound card output file descriptor, but
> the buffer is full, and the sound card is not running, what will then
> happen?"
> 
> 1) it will return with errno set to EAGAIN, because it is not ready for
>    writing
> 2) it will return with errno set to EPIPE, because there is a buffer
>    overflow

2 is better because EAGAIN would be returned also if buffer is
*temporarily* full.
Consider also that "retry again later" is definitely a misleading hint.

> In conclusion, I advice you to change the behaviour to what we as
> programmers expect, and sometimes program for. I would very much
> appriciate it, and I'm sure others will as well

Please understand that it's very hard to satisfy everybody and I'm not
sure it's a worthy goal.

That apart, I'm very interested to hear further technical reason to
change current behaviour.

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

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


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Anders Torger]

On Tuesday 17 September 2002 10.12, you wrote:
> Please use technical argumentations: pseudo statistical and
> subjective ones does not worth a lot.

Actually, that is exactly the type of argumentation you use yourself. 
It is not anything wrong with that either. It is always subjective why 
a certain technical behaviour is a better one than others.

And, I still think a good design rule is to make it behave like it 
traditionally behaves, so experienced programmers will get the expected 
behaviour.

> > "If the sound card output buffer is full of data, and it is not
> > running, what would happen if you poll that file descriptor for
> > writing"
> >
> > 1) it will block, because it is not ready for writing
> > 2) it would not block, because it would then block forever
>
> 2 is better because the programmer can know the reason of failure.
> With 1 the programmer will not receive enough info to detect it (also
> using a timeout)

This is the only reason I've heard for this feature, that it makes 
problems easier to detect. That you can easier detect a bug in a 
program. There is thus actually no functional use. Could you give me 
another argument than this bug detection thing why the current 
behaviour is useful?

However, I actually think that the current behaviour makes it *harder* 
to detect the bug. It was for me. I got XRUN on the output process so I 
thought there was some problem with buffer underrun, and wondered if 
the card had started automatically anyway and searched for problems 
there.

A deadlock is instead easy to detect. Attach with gdb and see where it 
has blocked, and from that it is easy to understand, well, this file 
descriptor never gets ready for writing, so the sound card cannot be 
running. Blocking indicates one error. XRUN indicates more than one.

> > "If you write to a non-blocking sound card output file descriptor,
> > but the buffer is full, and the sound card is not running, what
> > will then happen?"
> >
> > 1) it will return with errno set to EAGAIN, because it is not ready
> > for writing
> > 2) it will return with errno set to EPIPE, because there is a
> > buffer overflow
>
> 2 is better because EAGAIN would be returned also if buffer is
> *temporarily* full.
> Consider also that "retry again later" is definitely a misleading
> hint.

You can think so, but if there is another thread, it is not true. Also, 
this is how other file descriptor works, they are exactly as mean. 
Making ALSA "nicer" in your opinion will just confuse programmers who 
know how file descriptors work in Unix.

And still, your argument is still only for bug detection, and a bug 
causing this problem is easy to detect with the established file 
descriptor behaviour.

> Please understand that it's very hard to satisfy everybody and I'm
> not sure it's a worthy goal.

Satisfy most people and do good design is a worthy goal I think. My 
(and others) arguments are mainly these:

1) File descriptors should have the standard behaviour, because 
programmers expect it, and will then not confuse dead-lock bugs with 
overflows.
2) The standard behaviour has a use, blocking on write, starting the 
card from another thread or process.
3) It is good design to use established behaviours. Now the established 
behaviour also gives functional and advantages in use, so it should be 
a straight-forward decision.

> That apart, I'm very interested to hear further technical reason to
> change current behaviour.

Yes, I'm very interested in further reasoning as well. I am firm but 
humble, I can change my mind, but so far I have not seen any convincing 
arguments for having a special behaviour for ALSA file descriptors.

/Anders Torger


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Paul Davis]

>Please understand that it's very hard to satisfy everybody and I'm not
>sure it's a worthy goal.

Who do we know that would be unsatisfied by the proposed change in the
behaviour of poll(2) on an ALSA device?

--p


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Clemens Ladisch]

Anders Torger wrote:
> On Monday 16 September 2002 21.31, you [Abramo Bagnara] wrote:
> > I think that the best behaviour is the current and it's also the
> > simplest to describe and to understand: poll/select never blocks when
> > there is nothing to wait.
> >
> > ... and in PREPARED state definitely there's nothing to wait from
> > sound card.
>
> I don't agree. (...)
>
> Also, as we have noted, there is no real use for the current behaviour
> (at least no-one has said what it is), while there is use for the
> proper work-as-all-other-file-descriptors behaviour.

IMHO the current behaviour is the proper behaviour as implemented by other
file descriptors, and as mandated by POSIX.

<http://www.opengroup.org/onlinepubs/007904975/functions/write.html>
says regarding pipes, FIFOs and sockets:
| The write() function shall fail if:
| (...)
| [EPIPE]
| An attempt is made to write to a pipe or FIFO that is not open for
| reading by any process, or that only has one end open.
| (...)
| A write was attempted on a socket that is shut down for writing, or is
| no longer connected.


> It makes sense to block, there may be another thread, or even another
> process starting the sound card.

In the cases cited above, there may be another thread/process which will
open the other end of the FIFO, or connect to the socket. But write() only
looks at the state of the file descriptor at the time the call is made,
and does not take into regard what _might_ happen in the future.

The 'prepared' state is equivalent to the EPIPE cases above because it's a
state in which the pcm device is _not_ reading data.

> And it makes sense to return EAGAIN when writing to a non-blocking
> socket when it is not ready to accept data.

write() (or send()) blocks or returns EAGAIN if the local buffer is full
and data is being sent away, but fails if there isn't somebody listening
at the other end.

> * It simplifies multi-threaded programming

This might be true in a general sense, but the semantics of the
Linux/Unix/POSIX/whateverix API have not been designed with multi-
threading in mind, and ALSA tries to be compatible/consistent with that.


Regards,
Clemens



-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Anders Torger]

On Tuesday 17 September 2002 11.05, you wrote:
> Anders Torger wrote:
> > On Monday 16 September 2002 21.31, you [Abramo Bagnara] wrote:
> > > I think that the best behaviour is the current and it's also the
> > > simplest to describe and to understand: poll/select never blocks
> > > when there is nothing to wait.
> > >
> > > ... and in PREPARED state definitely there's nothing to wait from
> > > sound card.
> >
> > I don't agree. (...)
> >
> > Also, as we have noted, there is no real use for the current
> > behaviour (at least no-one has said what it is), while there is use
> > for the proper work-as-all-other-file-descriptors behaviour.
>
> IMHO the current behaviour is the proper behaviour as implemented by
> other file descriptors, and as mandated by POSIX.
>
> <http://www.opengroup.org/onlinepubs/007904975/functions/write.html>
>
> says regarding pipes, FIFOs and sockets:
> | The write() function shall fail if:
> | (...)
> | [EPIPE]
> | An attempt is made to write to a pipe or FIFO that is not open for
> | reading by any process, or that only has one end open.
> | (...)
> | A write was attempted on a socket that is shut down for writing, or
> | is no longer connected.
> |
> > It makes sense to block, there may be another thread, or even
> > another process starting the sound card.
>
> In the cases cited above, there may be another thread/process which
> will open the other end of the FIFO, or connect to the socket. But
> write() only looks at the state of the file descriptor at the time
> the call is made, and does not take into regard what _might_ happen
> in the future.
>
> The 'prepared' state is equivalent to the EPIPE cases above because
> it's a state in which the pcm device is _not_ reading data.
>
> > And it makes sense to return EAGAIN when writing to a non-blocking
> > socket when it is not ready to accept data.
>
> write() (or send()) blocks or returns EAGAIN if the local buffer is
> full and data is being sent away, but fails if there isn't somebody
> listening at the other end.

Ok, this is a really good argument, thanks. Now I can see that the 
current behaviour is not obviously broken, as I thought first. However, 
this only applies if the analogy "sound card not runnning" = "no reader 
in the other end" is used, and I don't think it is very natural, since 
the reader in this case is the hardware, not another process. My 
suggested behaviour would also apply on the POSIX behaviour, it is just 
a matter of how one interprets the situation. And, I also think my 
suggested behaviour is useful, while the current behaviour just makes 
things a bit more difficult, although it is not a big thing.

However, with this explanation I understand your and Abramo's 
viewpoint, and I understand why it can be seen as not being broken, but 
instead a correct POSIX behaviour, so I'll stop arguing about this.

/Anders Torger


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Takashi Iwai]

At Tue, 17 Sep 2002 11:05:44 +0200 (METDST),
Clemens Ladisch wrote:
> 
> Anders Torger wrote:
> > On Monday 16 September 2002 21.31, you [Abramo Bagnara] wrote:
> > > I think that the best behaviour is the current and it's also the
> > > simplest to describe and to understand: poll/select never blocks when
> > > there is nothing to wait.
> > >
> > > ... and in PREPARED state definitely there's nothing to wait from
> > > sound card.
> >
> > I don't agree. (...)
> >
> > Also, as we have noted, there is no real use for the current behaviour
> > (at least no-one has said what it is), while there is use for the
> > proper work-as-all-other-file-descriptors behaviour.
> 
> IMHO the current behaviour is the proper behaviour as implemented by other
> file descriptors, and as mandated by POSIX.

good point.  referring to POSIX helps our decision.


> <http://www.opengroup.org/onlinepubs/007904975/functions/write.html>
> says regarding pipes, FIFOs and sockets:
> | The write() function shall fail if:
> | (...)
> | [EPIPE]
> | An attempt is made to write to a pipe or FIFO that is not open for
> | reading by any process, or that only has one end open.
> | (...)
> | A write was attempted on a socket that is shut down for writing, or is
> | no longer connected.
> 
> 
> > It makes sense to block, there may be another thread, or even another
> > process starting the sound card.
> 
> In the cases cited above, there may be another thread/process which will
> open the other end of the FIFO, or connect to the socket. But write() only
> looks at the state of the file descriptor at the time the call is made,
> and does not take into regard what _might_ happen in the future.
> 
> The 'prepared' state is equivalent to the EPIPE cases above because it's a
> state in which the pcm device is _not_ reading data.

but are you sure that this feature is really implemented?
on my system, write() to an FIFO which is not opened for read doesn't
fail, for example,
	% mkfifo /tmp/foo
	% cat /dev/random > /tmp/foo
and cat is blocked, not failed.

i'll check how poll() behaves...


Takashi


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[tomasz motylewski]

On Tue, 17 Sep 2002, Takashi Iwai wrote:

> 
> but are you sure that this feature is really implemented?
> on my system, write() to an FIFO which is not opened for read doesn't
> fail, for example,
> 	% mkfifo /tmp/foo
> 	% cat /dev/random > /tmp/foo
> and cat is blocked, not failed.

No, in this case open() blocks. cat is even not started, because the shell
waits for open().

If you open /tmp/foo for reading, then open() suceeds, cat starts and may
write. If you close the other end, the next write() from cat will return -1.

Best regards,
--
Tomasz Motylewski

P.S. ALSA has more possible states of fd than pipes which may be just
open/closed by the other side, and eventually full. This makes direct
comparision difficult.



-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Takashi Iwai]

At Tue, 17 Sep 2002 13:55:10 +0200 (CEST),
tomasz motylewski wrote:
> 
> On Tue, 17 Sep 2002, Takashi Iwai wrote:
> 
> > 
> > but are you sure that this feature is really implemented?
> > on my system, write() to an FIFO which is not opened for read doesn't
> > fail, for example,
> > 	% mkfifo /tmp/foo
> > 	% cat /dev/random > /tmp/foo
> > and cat is blocked, not failed.
> 
> No, in this case open() blocks. cat is even not started, because the shell
> waits for open().

ah, ok.  thanks for clarification.

> If you open /tmp/foo for reading, then open() suceeds, cat starts and may
> write. If you close the other end, the next write() from cat will return -1.

yes.  clearly.

> P.S. ALSA has more possible states of fd than pipes which may be just
> open/closed by the other side, and eventually full. This makes direct
> comparision difficult.

i feel like that, too.
but comparing the behavior gives us better understanding, at least.
so let's try a bit yet more.


if we regard the prepare state as "not ready", then write() should
return EPIPE.  this is the current implementation.

but at the same time, we can regard the perpare state as "ready for
write but waiting for trigger".   again from the citation:
 
| The write() function shall fail if:
| (...)
| [EPIPE]
| An attempt is made to write to a pipe or FIFO that is not open for
| reading by any process, or that only has one end open.
| (...)
| A write was attempted on a socket that is shut down for writing, or is
| no longer connected.

in the latter interpretation, the pipe/fifo is opened for reading
(already configured) and obviously it's not end open.  the pcm stream
is not shut down.   the stream is simply "not started".
this is the case in which the opposite reader process opened fifo but
don't start reading at all yet.

i.e. we can say that the prepare state doesn't match with the case
above -- therefore write() should be blocked.

or, is this the absolutely wrong interpretation?


Takashi


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Anders Torger]

On Tuesday 17 September 2002 14.52, you wrote:
> At Tue, 17 Sep 2002 13:55:10 +0200 (CEST),
>
> tomasz motylewski wrote:
> > On Tue, 17 Sep 2002, Takashi Iwai wrote:
> > > but are you sure that this feature is really implemented?
> > > on my system, write() to an FIFO which is not opened for read
> > > doesn't fail, for example,
> > > 	% mkfifo /tmp/foo
> > > 	% cat /dev/random > /tmp/foo
> > > and cat is blocked, not failed.
> >
> > No, in this case open() blocks. cat is even not started, because
> > the shell waits for open().
>
> ah, ok.  thanks for clarification.
>
> > If you open /tmp/foo for reading, then open() suceeds, cat starts
> > and may write. If you close the other end, the next write() from
> > cat will return -1.
>
> yes.  clearly.
>
> > P.S. ALSA has more possible states of fd than pipes which may be
> > just open/closed by the other side, and eventually full. This makes
> > direct comparision difficult.
>
> i feel like that, too.
> but comparing the behavior gives us better understanding, at least.
> so let's try a bit yet more.
>
>
> if we regard the prepare state as "not ready", then write() should
> return EPIPE.  this is the current implementation.
>
> but at the same time, we can regard the perpare state as "ready for
>
> write but waiting for trigger".   again from the citation:
> | The write() function shall fail if:
> | (...)
> | [EPIPE]
> | An attempt is made to write to a pipe or FIFO that is not open for
> | reading by any process, or that only has one end open.
> | (...)
> | A write was attempted on a socket that is shut down for writing, or
> | is no longer connected.
>
> in the latter interpretation, the pipe/fifo is opened for reading
> (already configured) and obviously it's not end open.  the pcm stream
> is not shut down.   the stream is simply "not started".
> this is the case in which the opposite reader process opened fifo but
> don't start reading at all yet.
>
> i.e. we can say that the prepare state doesn't match with the case
> above -- therefore write() should be blocked.
>
> or, is this the absolutely wrong interpretation?

I feel that one can interpret both ways, so it is a quite open choice. 
Either way, one can state POSIX behaviour. Then the question becomes: 
what is the most usable behaviour? I think blocking/EAGAIN is the 
simpler and more usable. The current behaviour can only be used to show 
that a program is buggy by generating a broken pipe instead of 
dead-lock (a trivial bug also), while blocking/EAGAIN can be used in 
threaded programs, and seems quite logical for many/most.

It would be interesting to know what the kernel mailing list would say 
about this issue.

/Anders Torger


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Clemens Ladisch]

Anders Torger wrote:
> On Tuesday 17 September 2002 14.52, you [Takashi] wrote:
> > At Tue, 17 Sep 2002 13:55:10 +0200 (CEST),
> > tomasz motylewski wrote:
> > > P.S. ALSA has more possible states of fd than pipes which may be
> > > just open/closed by the other side, and eventually full. This makes
> > > direct comparision difficult.
> >
> > i feel like that, too.
> > but comparing the behavior gives us better understanding, at least.
> > so let's try a bit yet more.
> >
> >
> > if we regard the prepare state as "not ready", then write() should
> > return EPIPE.  this is the current implementation.

Yes. But I've just realized that in this case write() must _always_ return
EPIPE, i.e. it would not allow filling the first buffer.

> > but at the same time, we can regard the perpare state as "ready for
> > write but waiting for trigger".   again from the citation:
> > | The write() function shall fail if:
> > | (...)
> > | [EPIPE]
> > | An attempt is made to write to a pipe or FIFO that is not open for
> > | reading by any process, or that only has one end open.
> > | (...)
> >
> > in the latter interpretation, the pipe/fifo is opened for reading
> > (already configured) and obviously it's not end open.  the pcm stream
> > is not shut down.   the stream is simply "not started".
> > this is the case in which the opposite reader process opened fifo but
> > don't start reading at all yet.

And the stream will start if the start threshold has been set (I think;
I've never used it).

> > i.e. we can say that the prepare state doesn't match with the case
> > above -- therefore write() should be blocked.
> >
> > or, is this the absolutely wrong interpretation?
>
> I feel that one can interpret both ways, so it is a quite open choice.
> Either way, one can state POSIX behaviour. Then the question becomes:
> what is the most usable behaviour?

I think we have only two choices for POSIX-compliant write() behaviour in
the prepared state:

1) Don't allow any writes. Always return EPIPE.
   (my interpretation above)

2) Allow writes until the buffer is full, then block.
   (Takashi's second interpretation)

The current ALSA implementation is an inconsistent mixture of both:
returning EPIPE means that it is impossible to write, but then it should
not have been possible for the first bufferfull to succeed.

And we want to be able to fill the first buffer, so IMHO 2) is the way to
go.


Regards,
Clemens



-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Anders Torger]

On Tuesday 17 September 2002 16.40, Clemens Ladisch wrote:
> > I feel that one can interpret both ways, so it is a quite open
> > choice. Either way, one can state POSIX behaviour. Then the
> > question becomes: what is the most usable behaviour?
>
> I think we have only two choices for POSIX-compliant write()
> behaviour in the prepared state:
>
> 1) Don't allow any writes. Always return EPIPE.
>    (my interpretation above)
>
> 2) Allow writes until the buffer is full, then block.
>    (Takashi's second interpretation)
>
> The current ALSA implementation is an inconsistent mixture of both:
> returning EPIPE means that it is impossible to write, but then it
> should not have been possible for the first bufferfull to succeed.
>
> And we want to be able to fill the first buffer, so IMHO 2) is the
> way to go.

So, are we going to see a change in behaviour here? It seems like 
everyone which has discussed this, except Abramo, wants to see a change 
to the second interpretation which is:

* write() blocks on blocking mode when output buffer is full, and 
  returns EAGAIN when in non-blocking mode.

* poll/select blocks when output buffer is full

...with no difference if the card is running or not. Today, it is a 
different behaviour when the card is not running, where write returns 
EPIPE (both blocking/non-blocking) and poll/select does not block.

The arguments for keeping the current behaviour is according to its 
supporter(s?):

 * It is easier to detect bugs which else would dead-lock the program
 * It is more logical, like a pipe with the hardware in the read end

The arguments for changing to the new are:

 * It is sometimes used in multi-threaded programs (fill buffer in one 
   thread, start from another).
 * The current behaviour has no use apart from detection of a trivial 
   dead-lock bug.
 * Especially in multi-threaded programs, the current behaviour with
   EPIPE can be confused with underruns or overflows, making the 
   "easier-to-detect-bug" feature to have the opposite effect.
 * It is a POSIX-compliant behaviour which the current is not
 * It is more logical, always same behaviour, no special case for cards
   not running
 * It seems to be the more popular choice, and would break very little
   if any if implemented.

Ok, I said I would stop argue about this, so sue me.

/Anders Torger


-------------------------------------------------------
This SF.NET email is sponsored by: AMD - Your access to the experts
on Hammer Technology! Open Source & Linux Developers, register now
for the AMD Developer Symposium. Code: EX8664
http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Anders Torger]

On Wednesday 18 September 2002 21.57, Anders Torger wrote:
> On Tuesday 17 September 2002 16.40, Clemens Ladisch wrote:
> > > I feel that one can interpret both ways, so it is a quite open
> > > choice. Either way, one can state POSIX behaviour. Then the
> > > question becomes: what is the most usable behaviour?
> >
> > I think we have only two choices for POSIX-compliant write()
> > behaviour in the prepared state:
> >
> > 1) Don't allow any writes. Always return EPIPE.
> >    (my interpretation above)
> >
> > 2) Allow writes until the buffer is full, then block.
> >    (Takashi's second interpretation)
> >
> > The current ALSA implementation is an inconsistent mixture of both:
> > returning EPIPE means that it is impossible to write, but then it
> > should not have been possible for the first bufferfull to succeed.
> >
> > And we want to be able to fill the first buffer, so IMHO 2) is the
> > way to go.
>
> So, are we going to see a change in behaviour here? It seems like
> everyone which has discussed this, except Abramo, wants to see a
> change to the second interpretation which is:
>
> * write() blocks on blocking mode when output buffer is full, and
>   returns EAGAIN when in non-blocking mode.
>
> * poll/select blocks when output buffer is full
>
> ...with no difference if the card is running or not. Today, it is a
> different behaviour when the card is not running, where write returns
> EPIPE (both blocking/non-blocking) and poll/select does not block.
>
> The arguments for keeping the current behaviour is according to its
> supporter(s?):
>
>  * It is easier to detect bugs which else would dead-lock the program
>  * It is more logical, like a pipe with the hardware in the read end
>
> The arguments for changing to the new are:
>
>  * It is sometimes used in multi-threaded programs (fill buffer in
> one thread, start from another).
>  * The current behaviour has no use apart from detection of a trivial
>    dead-lock bug.
>  * Especially in multi-threaded programs, the current behaviour with
>    EPIPE can be confused with underruns or overflows, making the
>    "easier-to-detect-bug" feature to have the opposite effect.
>  * It is a POSIX-compliant behaviour which the current is not
>  * It is more logical, always same behaviour, no special case for
> cards not running
>  * It seems to be the more popular choice, and would break very
> little if any if implemented.
>
> Ok, I said I would stop argue about this, so sue me.

Uhhh... I guess ignoring me works just as well :-)

/Anders Torger


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Takashi Iwai]

At Fri, 4 Oct 2002 10:14:09 +0200,
Anders Torger wrote:
> 
> Uhhh... I guess ignoring me works just as well :-)

not ignored but pending :)

Abramo, do you still have objection to change the default behavior?

i don't mind that even the new behavior is optional e.g. via
snd_pcm_sw_params.  but i believe the current behavior is not expected
as a normal one, so it's enough reason to change it.

also, if someone (Tim?) already has a patch, please send it here.
it seems my last patch doesn't work properly...


ciao,

Takashi


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Takashi Iwai wrote:
> 
> At Fri, 4 Oct 2002 10:14:09 +0200,
> Anders Torger wrote:
> >
> > Uhhh... I guess ignoring me works just as well :-)
> 
> not ignored but pending :)
> 
> Abramo, do you still have objection to change the default behavior?
> 
> i don't mind that even the new behavior is optional e.g. via
> snd_pcm_sw_params.  but i believe the current behavior is not expected
> as a normal one, so it's enough reason to change it.
> 
> also, if someone (Tim?) already has a patch, please send it here.
> it seems my last patch doesn't work properly...

For what it worths my objections are still there.

I'm strongly convinced that to have poll waiting for something that
cannot happens is a big mistake (also as an optional behaviour).

That apart I'm sure that to make a change in actual behaviour between
rcX and 1.0 is a professional suicide. However it's _your_ professional
suicide so... ;-)))

To resume, if you ask me, the answer is no.

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

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


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Takashi Iwai]

At Fri, 04 Oct 2002 20:04:00 +0200,
Abramo Bagnara wrote:
> 
> Takashi Iwai wrote:
> > 
> > At Fri, 4 Oct 2002 10:14:09 +0200,
> > Anders Torger wrote:
> > >
> > > Uhhh... I guess ignoring me works just as well :-)
> > 
> > not ignored but pending :)
> > 
> > Abramo, do you still have objection to change the default behavior?
> > 
> > i don't mind that even the new behavior is optional e.g. via
> > snd_pcm_sw_params.  but i believe the current behavior is not expected
> > as a normal one, so it's enough reason to change it.
> > 
> > also, if someone (Tim?) already has a patch, please send it here.
> > it seems my last patch doesn't work properly...
> 
> For what it worths my objections are still there.
> 
> I'm strongly convinced that to have poll waiting for something that
> cannot happens is a big mistake (also as an optional behaviour).

it CAN happen if you have multi-threads.
the problem is that we have no option to block the poll.


> That apart I'm sure that to make a change in actual behaviour between
> rcX and 1.0 is a professional suicide. However it's _your_ professional
> suicide so... ;-)))
 
yes, i know it well ;)

i don't like to change this inevitably, too.
and as mentioned above, i don't mind to add an option as sw_params,
etc. for the new behavior.

but the current behavior is incorrect from the interpretation of
POSIX.  so this must be a bug.
if we have to change it, then i would choose the new one, because it's
more intuitive without exception.


Takashi


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Takashi Iwai wrote:
> 
> it CAN happen if you have multi-threads.
> the problem is that we have no option to block the poll.

If you have multi-thread you have other alternative to do that.
OTOH application can't detect *why* poll is blocking with the change you
advocate.

> > That apart I'm sure that to make a change in actual behaviour between
> > rcX and 1.0 is a professional suicide. However it's _your_ professional
> > suicide so... ;-)))
> 
> yes, i know it well ;)
> 
> i don't like to change this inevitably, too.
> and as mentioned above, i don't mind to add an option as sw_params,
> etc. for the new behavior.
> 
> but the current behavior is incorrect from the interpretation of
> POSIX.  so this must be a bug.
> if we have to change it, then i would choose the new one, because it's
> more intuitive without exception.

As pointed by Clemens the current is the proper POSIX behaviour.

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

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


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Anders Torger]

On Monday 07 October 2002 14.07, you wrote:
> Takashi Iwai wrote:
> > it CAN happen if you have multi-threads.
> > the problem is that we have no option to block the poll.
>
> If you have multi-thread you have other alternative to do that.
> OTOH application can't detect *why* poll is blocking with the change
> you advocate.

This is a non-issue. I think it is larger risk to search for the wrong 
problem (like I did), that is beleiving that there is a buffer underrun 
or similar. This type of blocking bug is very easy to detect and debug, 
I don't think the bug-detection argument is important, and that is also 
the only argument for the current behaviour (apart from that it is bad 
to change APIs).

> > > That apart I'm sure that to make a change in actual behaviour
> > > between rcX and 1.0 is a professional suicide. However it's
> > > _your_ professional suicide so... ;-)))
> >
> > yes, i know it well ;)
> >
> > i don't like to change this inevitably, too.
> > and as mentioned above, i don't mind to add an option as sw_params,
> > etc. for the new behavior.
> >
> > but the current behavior is incorrect from the interpretation of
> > POSIX.  so this must be a bug.
> > if we have to change it, then i would choose the new one, because
> > it's more intuitive without exception.
>
> As pointed by Clemens the current is the proper POSIX behaviour.

Perhaps you missed it, but he actually changed his mind, I have cited 
below.

-----------------

I think we have only two choices for POSIX-compliant write() behaviour 
in the prepared state:

1) Don't allow any writes. Always return EPIPE.
   (my interpretation above)

2) Allow writes until the buffer is full, then block.
   (Takashi's second interpretation)

The current ALSA implementation is an inconsistent mixture of both:
returning EPIPE means that it is impossible to write, but then it should
not have been possible for the first bufferfull to succeed.

And we want to be able to fill the first buffer, so IMHO 2) is the way 
to go.


Regards,
Clemens

-----------------------------


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Anders Torger wrote:
> 
> On Monday 07 October 2002 14.07, you wrote:
> > Takashi Iwai wrote:
> > > it CAN happen if you have multi-threads.
> > > the problem is that we have no option to block the poll.
> >
> > If you have multi-thread you have other alternative to do that.
> > OTOH application can't detect *why* poll is blocking with the change
> > you advocate.
> 
> This is a non-issue. I think it is larger risk to search for the wrong
> problem (like I did), that is beleiving that there is a buffer underrun
> or similar. This type of blocking bug is very easy to detect and debug,
> I don't think the bug-detection argument is important, and that is also
> the only argument for the current behaviour (apart from that it is bad
> to change APIs).

I'm not speaking about programming bugs. Suppose the PCM is stopped by
another thread: you're screwed.
 
> > > > That apart I'm sure that to make a change in actual behaviour
> > > > between rcX and 1.0 is a professional suicide. However it's
> > > > _your_ professional suicide so... ;-)))
> > >
> > > yes, i know it well ;)
> > >
> > > i don't like to change this inevitably, too.
> > > and as mentioned above, i don't mind to add an option as sw_params,
> > > etc. for the new behavior.
> > >
> > > but the current behavior is incorrect from the interpretation of
> > > POSIX.  so this must be a bug.
> > > if we have to change it, then i would choose the new one, because
> > > it's more intuitive without exception.
> >
> > As pointed by Clemens the current is the proper POSIX behaviour.
> 

Perhaps you should reread Single Unix Specification, I quote
http://www.opengroup.org/onlinepubs/007904975/functions/poll.html

POLLIN 
            Data other than high-priority data may be read without
blocking. 


POLLOUT 
            Normal data may be written without blocking. 


No data may be read/written in current stream state in the case we are
discussing.


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

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


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Takashi Iwai]

At Mon, 07 Oct 2002 19:46:44 +0200,
Abramo Bagnara wrote:

> > > > but the current behavior is incorrect from the interpretation of
> > > > POSIX.  so this must be a bug.
> > > > if we have to change it, then i would choose the new one, because
> > > > it's more intuitive without exception.
> > >
> > > As pointed by Clemens the current is the proper POSIX behaviour.
> > 
> 
> Perhaps you should reread Single Unix Specification, I quote
> http://www.opengroup.org/onlinepubs/007904975/functions/poll.html
> 
> POLLIN 
>             Data other than high-priority data may be read without
> blocking. 
> 
> 
> POLLOUT 
>             Normal data may be written without blocking. 
> 
> 
> No data may be read/written in current stream state in the case we are
> discussing.

these flags are the conditions how read/write behaves when poll()
returns.  no problem that poll() itself is blocked in the prepare
state because it does NOT return until the pcm is ready.


Takashi


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Tim Goetze]

Abramo Bagnara wrote:

>Takashi Iwai wrote:
>> 
>> it CAN happen if you have multi-threads.
>> the problem is that we have no option to block the poll.
>
>If you have multi-thread you have other alternative to do that.
>OTOH application can't detect *why* poll is blocking with the change you
>advocate.

as has been said before, it is fairly easy to detect this.

and to reiterate, if this happens in a single-threaded app
the code is broken by design because it poll()s before 
starting the pcm.

i'm (we're) still waiting for your answers to these arguments. 

>> but the current behavior is incorrect from the interpretation of
>> POSIX.  so this must be a bug.
>> if we have to change it, then i would choose the new one, because it's
>> more intuitive without exception.
>
>As pointed by Clemens the current is the proper POSIX behaviour.

clemens quoted the write(2) behaviour POSIX mandates. this has 
nothing to do with the poll(2) behaviour.

quoting www.opengroup.org/onlinepubs/007904975/functions/poll.html
on POSIX-compliant poll events/revents flags:

<quote>
POLLERR An error has occurred on the device or stream. [...]
</quote>

which is not the case. in the scenario you describe (a single-
threaded app polling before the pcm is started) the error is 
within the calling code logic, but clearly not 'on the device 
or stream'.

the same document goes on to say:

<quote>
If none of the defined events have occurred on any selected file
descriptor, poll() shall wait at least timeout milliseconds for an
event to occur on any of the selected file descriptors. If the value
of timeout is 0, poll() shall return immediately. If the value of
timeout is -1, poll() shall block until a requested event occurs or
until the call is interrupted.
</quote>

there's nothing in this document that says the poll implementation
shall care about whether the condition polled for is likely or 
unlikely to occur.

it must be concluded that the current poll implementation violates
the POSIX standard.

tim



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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Jack O'Quin]

Abramo Bagnara <abramo.bagnara@libero.it> writes:

> For what it worths my objections are still there.
> 
> I'm strongly convinced that to have poll waiting for something that
> cannot happens is a big mistake (also as an optional behaviour).

The poll is waiting on some thread to start the PCM.  It is incorrect
to say that this "cannot happen".

> That apart I'm sure that to make a change in actual behaviour between
> rcX and 1.0 is a professional suicide. However it's _your_ professional
> suicide so... ;-)))

I am an advocate for high standards of compatibility.  But, this is
not a compatibility issue.

The current behavior fails in the case being discussed.  At worst, a
program that does not work under the current implementation will fail
differently after the change.  Some argue that the new failure symptom
is actually easier to debug, so even this may be an improvement.

The proposal permits appropriately programmed applications to do
something useful.  This behavior conforms to both the letter and
spirit of the X/Open standard, as far as I can see.

So, I think the change *should* be made, even at this late stage of
the release schedule.  (votes++)

Regards,
-- 
  Jack O'Quin
  Austin, Texas, USA



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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Paul Davis]

>IMHO the current behaviour is the proper behaviour as implemented by other
>file descriptors, and as mandated by POSIX.
>
><http://www.opengroup.org/onlinepubs/007904975/functions/write.html>
>says regarding pipes, FIFOs and sockets:
>| The write() function shall fail if:

the discussion here is about the behaviour of poll(2), not
write(2). as i read it, nobody has any problems with ALSA's write
implementation. 

--p


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

multiple devices/ possible bug in aplay or somewhere else?

[Guilhem Tardy]

Hi all,

I have tried playing audio on device 1 of a "pci2103" card through aplay, which
correctly displayed 2 devices and 1 subdevice each (aplay -l). The result was
that audio was still played on device 0, regardless of the -d parameter.

So my questions are:
 - are you aware of any bug in aplay or the ALSA library/driver frame work that
would cause this behaviour?
 - what other cards support multiple devices?


In an unrelated topic, did I miss a standard API for selecting the actual port
that a device captures from / plays out to, and is there any accepted default
mapping?

I would like to see the inclusion of the "pci2103" driver in the ALSA
distribution in the near future and before 1.0 at any rate. Advice on the
procedure for this to happen is welcome.

Cheers!
Guilhem.


__________________________________________________
Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com


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

Re: multiple devices/ possible bug in aplay or somewhere else?

[Jaroslav Kysela]

On Tue, 15 Oct 2002, Guilhem Tardy wrote:

> Hi all,
> 
> I have tried playing audio on device 1 of a "pci2103" card through aplay, which
> correctly displayed 2 devices and 1 subdevice each (aplay -l). The result was
> that audio was still played on device 0, regardless of the -d parameter.

-d is duration, use -D 'hw:0,1' or 'plughw:0,1'

> I would like to see the inclusion of the "pci2103" driver in the ALSA
> distribution in the near future and before 1.0 at any rate. Advice on the
> procedure for this to happen is welcome.

Send pointer to this list. We'll include the code, and / or comment what 
should be improved.

						Jaroslav

-----
Jaroslav Kysela <perex@suse.cz>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linux    http://www.suse.com



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

Re: multiple devices/ possible bug in aplay or somewhere else?

[Guilhem Tardy]

> -d is duration, use -D 'hw:0,1' or 'plughw:0,1'

Damn out-dated MAN pages! Thanks for the hint.

Guilhem.


__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Tim Goetze]

Abramo Bagnara wrote:

>> >I think that the best behaviour is the current and it's also the
>> >simplest to describe and to understand: poll/select never blocks when
>> >there is nothing to wait.
>> >
>> >... and in PREPARED state definitely there's nothing to wait from sound
>> >card.
>> 
>> you know that linux supports multi-threading, don't you?
>
>Oh, yes... and easy message passing between threads too.
>
>You get the point now?
>
>The usual rule of thumb is: "don't make in kernel space what is feasible
>in user space"

if you really believed in this rule, i'd expect you to start work on
moving the sequencer out of ring 0 asap. ;)

let's imagine:

* a single-threaded app. if the coder omits starting the stream before
poll, he'll quickly find out that nothing is played/recorded, and that
poll will hit the timeout, and consequently revise his code logic.

* a multi-threaded app. it is *very* convenient not to do the 'easy'
message passing for starting/stopping streams in many, many
applications. all you have to do in the 'engine' thread is poll and
process. i wonder if you can imagine how much easier things get when
things work this way.

and, afaict, fixing the behaviour actually removes code from the poll
logic in kernel.

i mean, alsa is great, but why do you have to make it a pita to code
for?

tim



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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Tim Goetze wrote:
> 
> Abramo Bagnara wrote:
> 
> >> >I think that the best behaviour is the current and it's also the
> >> >simplest to describe and to understand: poll/select never blocks when
> >> >there is nothing to wait.
> >> >
> >> >... and in PREPARED state definitely there's nothing to wait from sound
> >> >card.
> >>
> >> you know that linux supports multi-threading, don't you?
> >
> >Oh, yes... and easy message passing between threads too.
> >
> >You get the point now?
> >
> >The usual rule of thumb is: "don't make in kernel space what is feasible
> >in user space"
> 
> if you really believed in this rule, i'd expect you to start work on
> moving the sequencer out of ring 0 asap. ;)
> 
> let's imagine:
> 
> * a single-threaded app. if the coder omits starting the stream before
> poll, he'll quickly find out that nothing is played/recorded, and that
> poll will hit the timeout, and consequently revise his code logic.

It would be definitely not easy for the app. to detect *why* poll is
blocking and it'd needs time. I think it would be a bad solution.

> 
> * a multi-threaded app. it is *very* convenient not to do the 'easy'
> message passing for starting/stopping streams in many, many
> applications. all you have to do in the 'engine' thread is poll and
> process. i wonder if you can imagine how much easier things get when
> things work this way.

This argument might be applied to every message passing need between
threads. Do we want to change an useful semantic to have just another
way to do an already easy task? I don't believe so.

> i mean, alsa is great, but why do you have to make it a pita to code
> for?

I suppose you're exaggerating the thing to support your arguments, don't
you ;-)

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

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


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Tim Goetze]

Abramo Bagnara wrote:

>> let's imagine:
>> 
>> * a single-threaded app. if the coder omits starting the stream before
>> poll, he'll quickly find out that nothing is played/recorded, and that
>> poll will hit the timeout, and consequently revise his code logic.
>
>It would be definitely not easy for the app. to detect *why* poll is
>blocking and it'd needs time. I think it would be a bad solution.

snd_pcm_state_t s = snd_pcm_state (pcm); // or
$ cat /proc/asound/card0/pcm0c/sub0/status # if all else fails.

are enough to enlighten the coder in this case. 

besides, if this happens in a single-threaded program, the code is
broken and should be fixed at coding, not execution time.

>> * a multi-threaded app. it is *very* convenient not to do the 'easy'
>> message passing for starting/stopping streams in many, many
>> applications. all you have to do in the 'engine' thread is poll and
>> process. i wonder if you can imagine how much easier things get when
>> things work this way.
>
>This argument might be applied to every message passing need between
>threads. Do we want to change an useful semantic to have just another
>way to do an already easy task? I don't believe so.

then take a look at how /dev/rtc does it. it does periodic irqs, 
much like a pcm. it is perfectly legal to poll /dev/rtc without
setting it to trigger, in which case it will block until timeout. 

i don't see why alsa has to do things differently, it is supposed to
be advanced *linux* sound arch after all, so make it act like other 
linux devices do, please.

>> i mean, alsa is great, but why do you have to make it a pita to code
>> for?
>
>I suppose you're exaggerating the thing to support your arguments, don't
>you ;-)

nope. coding the workaround around the broken poll behaviour 
definitely was a pita.

besides, i don't get what you aim for. you're doing things in
a non-standard way, and coders don't understand it. don't you
care about your users? and if you do, don't you care about 
complying with linux standards?

tim



-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Anders Torger]

On Tuesday 17 September 2002 15.03, you wrote:
> >IMHO the current behaviour is the proper behaviour as implemented by
> > other file descriptors, and as mandated by POSIX.
> >
> ><http://www.opengroup.org/onlinepubs/007904975/functions/write.html>
> >
> >says regarding pipes, FIFOs and sockets:
> >| The write() function shall fail if:
>
> the discussion here is about the behaviour of poll(2), not
> write(2). as i read it, nobody has any problems with ALSA's write
> implementation.

I expected write with EAGAIN instead of EPIPE when writing to a full 
buffer on a prepared card. If poll blocks, EAGAIN on non-blocking 
write, and blocking on blocking write is the natural behaviour.

/Anders Torger


-------------------------------------------------------
Sponsored by: AMD - Your access to the experts on Hammer Technology! 
Open Source & Linux Developers, register now for the AMD Developer 
Symposium. Code: EX8664 http://www.developwithamd.com/developerlab

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Paul Davis wrote:
> 
> 
>  [ abramo: please forward to alsa-devel@lists.sourceforge.net. thanks. ]
> 
> >I'm strongly convinced that to have poll waiting for something that
> >cannot happens is a big mistake (also as an optional behaviour).
> 
> there are several, perhaps even lots, of other device drivers in the
> linux kernel that do this.

Some examples please.

> >That apart I'm sure that to make a change in actual behaviour between
> >rcX and 1.0 is a professional suicide. However it's _your_ professional
> >suicide so... ;-)))
> 
> not *one* person on alsa-devel has described software that would be
> broken by this change.

You'll hear the screams *after* the change has been done and not before.
This is what happens all the times and I'm sure you understand why.

> given that jaroslav is already changing the API between rcX and rcZ,
> this doesn't seem like much of a problem, anyway.

This is not true as far as I can tell. Jaroslav has made the changes an
option selectable at compile time. Consider also that he made a change
that break the compilation, while the case we are discussing is more
severe: the application still compiles but we'd have a different
behaviour.

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

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


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Paul Davis wrote:
> 
> >I'm not speaking about programming bugs. Suppose the PCM is stopped by
> >another thread: you're screwed.
> 
> why are you screwed? you're waiting (presumably) for data/space to be
> ready in the PCM device. there isn't any (or more precisely, you're
> waiting for changes in the state of data/space, and there are none). i
> don't see the problem.

The thread has no way to detect what's the cause of data/space lack
without busy loop or delaying.

> >> > As pointed by Clemens the current is the proper POSIX behaviour.
> >>
> >
> >Perhaps you should reread Single Unix Specification, I quote
> >http://www.opengroup.org/onlinepubs/007904975/functions/poll.html
> >
> >POLLIN
> >            Data other than high-priority data may be read without
> >blocking.
> >
> >
> >POLLOUT
> >            Normal data may be written without blocking.
> >
> >
> >No data may be read/written in current stream state in the case we are
> >discussing.
> 
> but nobody has suggested that poll(2) should return any flags with
> these bits set. the issue, i thought, was what should write(2) do ...

No, the issue was about poll and write.
The point is that stream is in bad state wrt read/write, this is the
reason why poll should return POLLERR.

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

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


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

Re: Why do I get broken pipe on write to a pcm in statePREPARED?

[Clemens Ladisch]

Abramo Bagnara wrote:
> > >No data may be read/written in current stream state in the case we are
> > >discussing.
> (...)
>
> The point is that stream is in bad state wrt read/write, this is the
> reason why poll should return POLLERR.

I think the stream is _not_ in a bad state because one buffer of data can
(and has) be written. The reason for not allowing further writes is that
the buffer is full, and not that the device wouldn't accept any data at
all. This is similar to the behaviour of a pipe with the reading end
opened by an application which currently doesn't read from the pipe, in
contrast to a pipe with the read end not opened at all.


Regards
Clemens



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