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]

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