Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

[Jack O'Quin]

Abramo Bagnara <[EMAIL PROTECTED]> 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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:[EMAIL PROTECTED]

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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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:[EMAIL PROTECTED]

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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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:


POLLERR An error has occurred on the device or stream. [...]


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:


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.


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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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:[EMAIL PROTECTED]

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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

[Abramo Bagnara]

Paul Davis wrote:
> 
> 
>  [ abramo: please forward to [EMAIL PROTECTED] 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:[EMAIL PROTECTED]

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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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:[EMAIL PROTECTED]

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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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.
> >
> >
> >
> >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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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.
>
>
>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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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.


> 
> 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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.
>
> 
>
> 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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:[EMAIL PROTECTED]

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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] 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:[EMAIL PROTECTED]

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
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

[Tim Goetze]

Takashi Iwai wrote:

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

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

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

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

tim



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

[Jaroslav Kysela]

On Thu, 12 Sep 2002, Takashi Iwai wrote:

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

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

Jaroslav

-
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linuxhttp://www.suse.com



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

[Tim Goetze]

Takashi Iwai wrote:

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

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

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

tim



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

[Tim Goetze]

Anders Torger wrote:
>On Wednesday 11 September 2002 23.52, you wrote:
>> Anders Torger wrote:
[...]
>> >The problem here is that the output buffer is full, the pcm is not
>> >RUNNING, but the file descriptor gets triggered anyway. When can
>> > that happen?
>>
>> we had a hauntingly similar discussion about this a few months ago,
>> maybe a year. iirc everybody considered the pcm behaviour broken,
>> except for the alsa coders.
>>
>> seeing that you come to the same conclusion makes me again vote
>> for changing this behaviour to 'poll/select blocks until running'.
>
>I shall be humble in this question, but of what I know now, the 
>behaviour does indeed seem broken. I get the effect "program stops 
>working when software buffer > hardware buffer", which would not happen 
>if it blocked as expected. It is harder for me to see what is the 
>advantage of the current behaviour, apart from that an obviously buggy 
>program gets a broken pipe instead of blocking infinitely. However, I 
>don't think that very small advantage justifies breaking programs that 
>expect sound cards file descriptors to behave as ordinary files.

if the api can still be changed every now and then, i don't see why
one would avoid a fix here to avoid compatibility problems. actually 
i don't think there are applications out there that make use of this
'feature', because it defies human logic (as your case shows us
again). and it is hard to imagine code logic that is based on 'poll/
select returns immediately', everyone rather has to work around it.

>So, I would appriciate to get a full explanation of why the behaviour 
>is like it is.

me too (still ;).

tim

ps: cannot say much about xruns in readX access -- i've only done 
mmap()d IO so far, which seems very reliable with an ice1712 and
an emu8k here.



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

[Tim Goetze]

Anders Torger wrote:

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

we had a hauntingly similar discussion about this a few months ago,
maybe a year. iirc everybody considered the pcm behaviour broken,
except for the alsa coders. 

seeing that you come to the same conclusion makes me again vote 
for changing this behaviour to 'poll/select blocks until running'.

tim



---
In remembrance
www.osdn.com/911/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel

Re: [Alsa-devel] Why do I get broken pipe on write to a pcm in statePREPARED?

[Jaroslav Kysela]

On Wed, 11 Sep 2002, Anders Torger wrote:

> I use a RME9652 hammerfall with two periods (the hardware is that way).
> 
> I watch a file descriptor associated to the output with select(), when 
> it gets ready for writing, I write data to the pcm with 
> snd_pcm_writen(). In the beginning, the state of the pcm is PREPARED.
> 
> What I would expect then, is that the file descriptor is ready for 
> writing until the two periods has been filled with data, and then 
> select will block (output buffers full, sound card not running). But 
> instead, when the two periods is filled with data, select() still 
> returns and says that the file descriptor is ready for writing, but 
> when calling snd_pcm_writen(), it returns -EPIPE. The pcm state is 
> still PREPARED.
> 
> What is wrong? Is it me (probably), or is it alsa?

You should also check for POLLERR. I'm not sure, that it's necessary to 
return POLLOUT together with POLLERR in that case. Anyway, application 
should check for POLLERR at first and then write data.

Jaroslav

-
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project  http://www.alsa-project.org
SuSE Linuxhttp://www.suse.com




---
In remembrance
www.osdn.com/911/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel