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

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?

[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]

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?

[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?

[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?

[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?

[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 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?

[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

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?

[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 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?

[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?

[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?

[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?

[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?

[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

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 instatePREPARED?

[Abramo Bagnara]

Clemens Ladisch wrote:
> 
> 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.

??? With this message now I'm very confused about what you wish...

Can you resume to me the comparison between current and wanted behaviour
wrt poll for both playback and capture. Leave apart read/write at least
for now.

A table would be easier to understand ;-)

-- 
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 instatePREPARED?

[Clemens Ladisch]

Abramo Bagnara wrote:
>
> Clemens Ladisch wrote:
> >
> > Abramo Bagnara wrote:
> > >
> > > 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.
>
> ??? With this message now I'm very confused about what you wish...

I changed my mind about how the POSIX standard fits to our problem case.

> Can you resume to me the comparison between current and wanted behaviour
> wrt poll for both playback and capture.

The behaviour of polling during capture is just fine:

RUNNING: block until avail_min is available, then return POLLIN
DRAINING: return POLLIN until buffer is empty, then return POLLERR
(other states: POLLERR)

The current behaviour for playback is:

PREPARED: return POLLOUT until the buffer is full, then return POLLERR
RUNNING: block until avail_min can be written, then return POLLOUT
DRAINING: block (until state changes)
(other states: POLLERR)

I want the behaviour in the PREPARED state to be similar to the RUNNING
state, i.e. return POLLOUT until the buffer is full, then block.

My reason for this is that a buffer overflow in the PREPARED state is
similar to a pipe connected to an application which currently doesn't read
from the pipe (-> blocking), and not a pipe which isn't connected at all
(-> EPIPE). And as Anders pointed out at the start of this thread, there
are situations where this case isn't an error.


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 instatePREPARED?

[Anders Torger]

On Wednesday 09 October 2002 09.52, Clemens Ladisch wrote:
> Abramo Bagnara wrote:
> > Clemens Ladisch wrote:
> > > Abramo Bagnara wrote:
> > > > 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.
> >
> > ??? With this message now I'm very confused about what you wish...
>
> I changed my mind about how the POSIX standard fits to our problem
> case.
>
> > Can you resume to me the comparison between current and wanted
> > behaviour wrt poll for both playback and capture.
>
> The behaviour of polling during capture is just fine:
>
> RUNNING: block until avail_min is available, then return POLLIN
> DRAINING: return POLLIN until buffer is empty, then return POLLERR
> (other states: POLLERR)
>
> The current behaviour for playback is:
>
> PREPARED: return POLLOUT until the buffer is full, then return
> POLLERR RUNNING: block until avail_min can be written, then return
> POLLOUT DRAINING: block (until state changes)
> (other states: POLLERR)
>
> I want the behaviour in the PREPARED state to be similar to the
> RUNNING state, i.e. return POLLOUT until the buffer is full, then
> block.

Why not have the same behaviour for polling during capture? Reading 
from a not-yet-started sound card is useful in the same way that 
writing to a not-yet-started sound card is useful. Perhaps especially 
in low-latency multi-threaded applications, when you want to start 
reading (or writing) as soon as possible after the sound card has been 
started (this can be accomplished in other ways of course). If poll 
keeps returning POLLERR it is no use. Blocking in both cases is better, 
and in my humble opinion more logical behaviour. I don't think having a 
special case for the prepared state in read or write is useful.

/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 instatePREPARED?

[James Courtier-Dutton]

Clemens Ladisch wrote:

>The behaviour of polling during capture is just fine:
>
>RUNNING: block until avail_min is available, then return POLLIN
>DRAINING: return POLLIN until buffer is empty, then return POLLERR
>(other states: POLLERR)
>
>The current behaviour for playback is:
>
>PREPARED: return POLLOUT until the buffer is full, then return POLLERR
>
Why would the buffer get full in PREPARED state ?
Surely any sensible, "start_threshold" should cause the state to change 
to RUNNING before the buffer is full.
I can't see any reason to not to use "start_threshold" in order to get 
from PREPARED to RUNNING.

>RUNNING: block until avail_min can be written, then return POLLOUT
>DRAINING: block (until state changes)
>(other states: POLLERR)
>
>I want the behaviour in the PREPARED state to be similar to the RUNNING
>state, i.e. return POLLOUT until the buffer is full, then block.
>
>My reason for this is that a buffer overflow in the PREPARED state is
>similar to a pipe connected to an application which currently doesn't read
>from the pipe (-> blocking), and not a pipe which isn't connected at all
>(-> EPIPE). And as Anders pointed out at the start of this thread, there
>are situations where this case isn't an error.
>
>
>Regards,
>Clemens
>
>  
>

Cheers
James




-------------------------------------------------------
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 instatePREPARED?

[Anders Torger]

On Wednesday 09 October 2002 15.28, you wrote:
> Clemens Ladisch wrote:
> >The behaviour of polling during capture is just fine:
> >
> >RUNNING: block until avail_min is available, then return POLLIN
> >DRAINING: return POLLIN until buffer is empty, then return POLLERR
> >(other states: POLLERR)
> >
> >The current behaviour for playback is:
> >
> >PREPARED: return POLLOUT until the buffer is full, then return
> > POLLERR
>
> Why would the buffer get full in PREPARED state ?
> Surely any sensible, "start_threshold" should cause the state to
> change to RUNNING before the buffer is full.
> I can't see any reason to not to use "start_threshold" in order to
> get from PREPARED to RUNNING.

Because another thread that should start the card is not ready yet. In 
threaded programming it may be fully natural to first fill the output 
buffer and then start the card from another thread. Of course, you can 
always adapt to how it works (for example if there would always be a 
start threshold which could not be changed), but it is best if poll() 
works in a way that is expected, and is conforming to standards.

If poll() behaviour is changed to the proposed, we will not only get a 
more clear standard conformance (what is conforming or not is however 
always a question of interpretation, since there is no relevant 
standard that directly relates to sound cards), but a more flexible API 
in terms of how to design your multi-threaded/process applications.

/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 instatePREPARED?

[Tim Goetze]

James Courtier-Dutton wrote:

>Clemens Ladisch wrote:
>
>>The behaviour of polling during capture is just fine:
>>
>>RUNNING: block until avail_min is available, then return POLLIN
>>DRAINING: return POLLIN until buffer is empty, then return POLLERR
>>(other states: POLLERR)
>>
>>The current behaviour for playback is:
>>
>>PREPARED: return POLLOUT until the buffer is full, then return POLLERR
>>
>Why would the buffer get full in PREPARED state ?
>Surely any sensible, "start_threshold" should cause the state to change 
>to RUNNING before the buffer is full.
>I can't see any reason to not to use "start_threshold" in order to get 
>from PREPARED to RUNNING.

there may be more work to do before actually starting the pcm:
delay line allocation, caching waves stored on disk, preparing
intermediate buffers for writing to disk, creating fftw plans 
etc etc. having the pcm kick off before this work is complete is 
not sensible. 

of course this depends on the particular application, but it 
is good that alsa doesn't push a certain model of app design 
here i think.

in fact, imo every feature that 'thinks for the programmer' is 
a risky thing because it narrows the choice of app designs.

>>RUNNING: block until avail_min can be written, then return POLLOUT
>>DRAINING: block (until state changes)
>>(other states: POLLERR)
>>
>>I want the behaviour in the PREPARED state to be similar to the RUNNING
>>state, i.e. return POLLOUT until the buffer is full, then block.
>>
>>My reason for this is that a buffer overflow in the PREPARED state is
>>similar to a pipe connected to an application which currently doesn't read
>>from the pipe (-> blocking), and not a pipe which isn't connected at all
>>(-> EPIPE). And as Anders pointed out at the start of this thread, there
>>are situations where this case isn't an error.

agree.

i see the current behaviour as another case where alsa tries to 
think for you. you know my ceterum censeo.

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 pcminstatePREPARED?

[Abramo Bagnara]

Clemens Ladisch wrote:
> 
> The current behaviour for playback is:
> 
> PREPARED: return POLLOUT until the buffer is full, then return POLLERR
> RUNNING: block until avail_min can be written, then return POLLOUT
> DRAINING: block (until state changes)
> (other states: POLLERR)
> 
> I want the behaviour in the PREPARED state to be similar to the RUNNING
> state, i.e. return POLLOUT until the buffer is full, then block.

Please reread with me SusV3:

POLLOUT: Normal data may be written without blocking.

When buffer is not full we have to return POLLOUT, but when buffer is
full the point is *not* that file cannot be written without blocking,
the point is that file cannot be written (because we'd return an error)

See?

Now the point is another: it's correct to return an error when buffer is
full or it's better to block?

My answer is that proposed behaviour is illogical if the programmer take
in account single-threading (i.e. my application have exclusive control
of PCM):
- in blocking mode we should delay (waiting for what?)
- in nonblocking mode we should return -EAGAIN (why try again?)

OTOH I agree that if the programmer consider multi-threading all the
illogicity goes away.

I think this could be faced with an appropriate documentation.

I've still some residual doubts:
- how many applications out there we will break?
- I'm almost sure that alsa-lib need to be changed in several places to
follow this: who will do that? I'm thinking expecially to PCM chains and
pcm_share.

Ok, iff:
- Jaroslav agrees too
- somebody do the patch for write *and* poll, correct the documentation
and add a special paragraph explaining multithreading POV, correct
alsa-lib and test *all* the PCM classes

you'll have my vote (FWIW of course ;-).

Thanks for your patience anyway.

-- 
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 instatePREPARED?

[Abramo Bagnara]

Anders Torger wrote:
> 
> On Wednesday 09 October 2002 09.52, Clemens Ladisch wrote:
> > Abramo Bagnara wrote:
> > > Clemens Ladisch wrote:
> > > > Abramo Bagnara wrote:
> > > > > 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.
> > >
> > > ??? With this message now I'm very confused about what you wish...
> >
> > I changed my mind about how the POSIX standard fits to our problem
> > case.
> >
> > > Can you resume to me the comparison between current and wanted
> > > behaviour wrt poll for both playback and capture.
> >
> > The behaviour of polling during capture is just fine:
> >
> > RUNNING: block until avail_min is available, then return POLLIN
> > DRAINING: return POLLIN until buffer is empty, then return POLLERR
> > (other states: POLLERR)
> >
> > The current behaviour for playback is:
> >
> > PREPARED: return POLLOUT until the buffer is full, then return
> > POLLERR RUNNING: block until avail_min can be written, then return
> > POLLOUT DRAINING: block (until state changes)
> > (other states: POLLERR)
> >
> > I want the behaviour in the PREPARED state to be similar to the
> > RUNNING state, i.e. return POLLOUT until the buffer is full, then
> > block.
> 
> Why not have the same behaviour for polling during capture? Reading
> from a not-yet-started sound card is useful in the same way that
> writing to a not-yet-started sound card is useful. Perhaps especially
> in low-latency multi-threaded applications, when you want to start
> reading (or writing) as soon as possible after the sound card has been
> started (this can be accomplished in other ways of course). If poll
> keeps returning POLLERR it is no use. Blocking in both cases is better,
> and in my humble opinion more logical behaviour. I don't think having a
> special case for the prepared state in read or write is useful.

Yes, I buy that.

-- 
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 pcminstatePREPARED?

[Jaroslav Kysela]

On Wed, 9 Oct 2002, Abramo Bagnara wrote:

> Clemens Ladisch wrote:
> > 
> > The current behaviour for playback is:
> > 
> > PREPARED: return POLLOUT until the buffer is full, then return POLLERR
> > RUNNING: block until avail_min can be written, then return POLLOUT
> > DRAINING: block (until state changes)
> > (other states: POLLERR)
> > 
> > I want the behaviour in the PREPARED state to be similar to the RUNNING
> > state, i.e. return POLLOUT until the buffer is full, then block.
> 
> Please reread with me SusV3:
> 
> POLLOUT: Normal data may be written without blocking.
> 
> When buffer is not full we have to return POLLOUT, but when buffer is
> full the point is *not* that file cannot be written without blocking,
> the point is that file cannot be written (because we'd return an error)
> 
> See?
> 
> Now the point is another: it's correct to return an error when buffer is
> full or it's better to block?
> 
> My answer is that proposed behaviour is illogical if the programmer take
> in account single-threading (i.e. my application have exclusive control
> of PCM):
> - in blocking mode we should delay (waiting for what?)
> - in nonblocking mode we should return -EAGAIN (why try again?)
> 
> OTOH I agree that if the programmer consider multi-threading all the
> illogicity goes away.
> 
> I think this could be faced with an appropriate documentation.
> 
> I've still some residual doubts:
> - how many applications out there we will break?
> - I'm almost sure that alsa-lib need to be changed in several places to
> follow this: who will do that? I'm thinking expecially to PCM chains and
> pcm_share.
> 
> Ok, iff:
> - Jaroslav agrees too
> - somebody do the patch for write *and* poll, correct the documentation
> and add a special paragraph explaining multithreading POV, correct
> alsa-lib and test *all* the PCM classes
> 
> you'll have my vote (FWIW of course ;-).

Thank you for your summary. I must admit that my silence in this thread
was caused that I see advantages for both behaviours. Anyway, we should
keep things as simple as possible, so I also prefer to choose only one
solution. Because the new proposal enhances usage possibilities, I take 
it.

						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 instatePREPARED?

[James Courtier-Dutton]

Anders Torger wrote:

>On Wednesday 09 October 2002 15.28, you wrote:
>  
>
>>Clemens Ladisch wrote:
>>    
>>
>>>The behaviour of polling during capture is just fine:
>>>
>>>RUNNING: block until avail_min is available, then return POLLIN
>>>DRAINING: return POLLIN until buffer is empty, then return POLLERR
>>>(other states: POLLERR)
>>>
>>>The current behaviour for playback is:
>>>
>>>PREPARED: return POLLOUT until the buffer is full, then return
>>>POLLERR
>>>      
>>>
>>Why would the buffer get full in PREPARED state ?
>>Surely any sensible, "start_threshold" should cause the state to
>>change to RUNNING before the buffer is full.
>>I can't see any reason to not to use "start_threshold" in order to
>>get from PREPARED to RUNNING.
>>    
>>
>
>Because another thread that should start the card is not ready yet. In 
>threaded programming it may be fully natural to first fill the output 
>buffer and then start the card from another thread. Of course, you can 
>always adapt to how it works (for example if there would always be a 
>start threshold which could not be changed), but it is best if poll() 
>works in a way that is expected, and is conforming to standards.
>
>If poll() behaviour is changed to the proposed, we will not only get a 
>more clear standard conformance (what is conforming or not is however 
>always a question of interpretation, since there is no relevant 
>standard that directly relates to sound cards), but a more flexible API 
>in terms of how to design your multi-threaded/process applications.
>
>/Anders Torger
>
>  
>
Ok, as far as Iam concerned, my application will not care. It never 
reaches the "PREPARED, buffer full" state because I use "start_threshold".
Although my application is multi-treaded, all the audio out happens in a 
single thread. Other threads do the grabbing  the data of the hard disk 
etc. and  buffering it in memory.

I do think that any poll should block unless data can be written to the 
file handle irrespective of the BLOCK/NON-BLOCK status of the file 
handle. BLOCK/NON-BLOCK should only effect open and write calls, not 
poll calls.

I don't understand which applications prefer: -
1) "PREPARED: return POLLOUT until the buffer is full, then return POLLERR."
and which would prefer (as suggested): -
2) "PREPARED: return POLLOUT until the buffer is full, then BLOCK."

As I understand it, the poll works correctly in RUNNING state?
I think (2) would basically kill all single thread apps so on balance, I 
think (1) is the best to go with for now.

The application I have thought of is that an application might want to 
fill many file handles/streams buffers but keep them in PREPARED state. 
Then release all the channels at the same time so that they play in 
sync. But for that one does not need to do any polling in PREPARED 
state. One just does snd_pcm_write until one gets an error.

I guess the solution to all this would be to provide two different 
poll/snd_pcm_wait calls so the application writer can choose which 
behaviour they want. This would then make everyone happy, and also not 
break any old apps.

Another solution is for the application writer to use the pthreads 
"pthread_cond_wait()" to get one thread to wait until another thread has 
done some work. Then alsa would not have to change at all. ;-)

Cheers
James





-------------------------------------------------------
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 instatePREPARED?

[Anders Torger]

On Thursday 10 October 2002 04.15, James Courtier-Dutton wrote:
> I don't understand which applications prefer: -
> 1) "PREPARED: return POLLOUT until the buffer is full, then return
> POLLERR." and which would prefer (as suggested): -
> 2) "PREPARED: return POLLOUT until the buffer is full, then BLOCK."
>
> As I understand it, the poll works correctly in RUNNING state?
> I think (2) would basically kill all single thread apps so on
> balance, I think (1) is the best to go with for now.
>
> The application I have thought of is that an application might want
> to fill many file handles/streams buffers but keep them in PREPARED
> state. Then release all the channels at the same time so that they
> play in sync. But for that one does not need to do any polling in
> PREPARED state. One just does snd_pcm_write until one gets an error.

This is possible to do with (1) as well, actually it is only a slight  
difference. You will need to have non-blocking write in the above 
example, or else you are not sure that you fill the buffer at all, for 
example if the output buffer is 2048 frames, and you try to write 4096, 
which currently returns an error in blocking mode, but still the output 
buffer will be empty.

With non-blocking mode it works, you fill the buffer and currently you 
wait for EPIPE, with the new behaviour you would wait for EAGAIN 
instead. The (1) alternative is then more flexible in terms of 
application design. Changing the behaviour would of course break your 
example application if it specifically checks for EPIPE (and not just a 
generic error).

/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 instatePREPARED?

[Jaroslav Kysela]

On Thu, 10 Oct 2002, Anders Torger wrote:

> On Thursday 10 October 2002 04.15, James Courtier-Dutton wrote:
> > I don't understand which applications prefer: -
> > 1) "PREPARED: return POLLOUT until the buffer is full, then return
> > POLLERR." and which would prefer (as suggested): -
> > 2) "PREPARED: return POLLOUT until the buffer is full, then BLOCK."
> >
> > As I understand it, the poll works correctly in RUNNING state?
> > I think (2) would basically kill all single thread apps so on
> > balance, I think (1) is the best to go with for now.
> >
> > The application I have thought of is that an application might want
> > to fill many file handles/streams buffers but keep them in PREPARED
> > state. Then release all the channels at the same time so that they
> > play in sync. But for that one does not need to do any polling in
> > PREPARED state. One just does snd_pcm_write until one gets an error.
> 
> This is possible to do with (1) as well, actually it is only a slight  
> difference. You will need to have non-blocking write in the above 
> example, or else you are not sure that you fill the buffer at all, for 
> example if the output buffer is 2048 frames, and you try to write 4096, 
> which currently returns an error in blocking mode, but still the output 
> buffer will be empty.

Not true. The output buffer will be filled up and then EPIPE error will 
be returned. So first write 4096 results with 2048 and second with EPIPE.

						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 instatePREPARED?

[Anders Torger]

On Thursday 10 October 2002 16.21, Jaroslav Kysela wrote:
> On Thu, 10 Oct 2002, Anders Torger wrote:
> > On Thursday 10 October 2002 04.15, James Courtier-Dutton wrote:
> > > I don't understand which applications prefer: -
> > > 1) "PREPARED: return POLLOUT until the buffer is full, then
> > > return POLLERR." and which would prefer (as suggested): -
> > > 2) "PREPARED: return POLLOUT until the buffer is full, then
> > > BLOCK."
> > >
> > > As I understand it, the poll works correctly in RUNNING state?
> > > I think (2) would basically kill all single thread apps so on
> > > balance, I think (1) is the best to go with for now.
> > >
> > > The application I have thought of is that an application might
> > > want to fill many file handles/streams buffers but keep them in
> > > PREPARED state. Then release all the channels at the same time so
> > > that they play in sync. But for that one does not need to do any
> > > polling in PREPARED state. One just does snd_pcm_write until one
> > > gets an error.
> >
> > This is possible to do with (1) as well, actually it is only a
> > slight difference. You will need to have non-blocking write in the
> > above example, or else you are not sure that you fill the buffer at
> > all, for example if the output buffer is 2048 frames, and you try
> > to write 4096, which currently returns an error in blocking mode,
> > but still the output buffer will be empty.
>
> Not true. The output buffer will be filled up and then EPIPE error
> will be returned. So first write 4096 results with 2048 and second
> with EPIPE.

Uhmm... but if you use my own write() call wrappers, then my 
description is correct... eh... I guess I have used them too much :-)

Anyway, it still is possible to do the given scenario with (1), but you 
need to put the file descriptor into non-blocking mode first of course.

/Anders


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