David Ford wrote:
>
> a) not all drivers are created equal
> b) esd should check the return value anyway
In as much as several people did point out that a write is not guaranteed to
be complete and may be short, even when in blocking mode, you are perfectly
correct. In as much as this usually
a) not all drivers are created equal
b) esd should check the return value anyway
-d
Doug Ledford wrote:
> David Ford wrote:
> >
> > Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
> > writes to the socket without regard to return value. If the write only
On Tue, 20 Mar 2001 15:19:37 -0500, Doug Ledford <[EMAIL PROTECTED]> wrote:
> Why would esd get a short write() unless it is opening the file in non
> blocking mode (which I didn't see when I was working on the i810 sound
> driver)? If esd is writing to a file in blocking mode and that write is
On Tue, 20 Mar 2001, Doug Ledford wrote:
> Why would esd get a short write() unless it is opening the file in non
> blocking mode (which I didn't see when I was working on the i810 sound
> driver)? If esd is writing to a file in blocking mode and that write is
> returning short, then that
Not necessarily. For a write to a disk file, it would be an error to return a
short write except in an error situation. For devices, the rules are looser.
Quoting Stevens APUE p.406, "Some devices, notably terminals, networks, and any
SVR4 streams devices have the following two properties.
...
2
David Ford wrote:
>
> Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
> writes to the socket without regard to return value. If the write only accepted
> 2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
> 4097, not 2099. esd
Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
writes to the socket without regard to return value. If the write only accepted
2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
4097, not 2099. esd is incredibly bad about err
Pozsar Balazs wrote:
> Are you sure that the problem isn't at the mp3->raw conversino point? In
> mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2,
> but awfully on 2.4.
Positive. Anyway, the problem is solved now...I just want to investigate it a
little bit further
Pozsar Balazs wrote:
Are you sure that the problem isn't at the mp3-raw conversino point? In
mandrake for example, mpg123 is badly compiled, and plays nicely on 2.2,
but awfully on 2.4.
Positive. Anyway, the problem is solved now...I just want to investigate it a
little bit further because
Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
writes to the socket without regard to return value. If the write only accepted
2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
4097, not 2099. esd is incredibly bad about err
David Ford wrote:
Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
writes to the socket without regard to return value. If the write only accepted
2098 of 4096 bytes, the residual bytes are lost, esd will write the next packet at
4097, not 2099. esd is
Not necessarily. For a write to a disk file, it would be an error to return a
short write except in an error situation. For devices, the rules are looser.
Quoting Stevens APUE p.406, "Some devices, notably terminals, networks, and any
SVR4 streams devices have the following two properties.
...
2
On Tue, 20 Mar 2001, Doug Ledford wrote:
Why would esd get a short write() unless it is opening the file in non
blocking mode (which I didn't see when I was working on the i810 sound
driver)? If esd is writing to a file in blocking mode and that write is
returning short, then that sounds
On Tue, 20 Mar 2001 15:19:37 -0500, Doug Ledford [EMAIL PROTECTED] wrote:
Why would esd get a short write() unless it is opening the file in non
blocking mode (which I didn't see when I was working on the i810 sound
driver)? If esd is writing to a file in blocking mode and that write is
a) not all drivers are created equal
b) esd should check the return value anyway
-d
Doug Ledford wrote:
David Ford wrote:
Actually you probably upgraded to a non-broken version of esd. Stock esd -still-
writes to the socket without regard to return value. If the write only accepted
David Ford wrote:
a) not all drivers are created equal
b) esd should check the return value anyway
In as much as several people did point out that a write is not guaranteed to
be complete and may be short, even when in blocking mode, you are perfectly
correct. In as much as this usually is
16 matches
Mail list logo
