On Tue, 2016-12-13 at 14:39 +0200, Ahmed S. Darwish wrote:
> On Mon, Dec 12, 2016 at 3:22 PM, Tanu Kaskinen wrote:
> >
> > What's the status? Did you give the alternative fix a try? Or should we
> > go with the ringbuffer-based fix?
> >
>
> pa_stream_begin_write() was simpler
On Mon, Dec 12, 2016 at 3:22 PM, Tanu Kaskinen wrote:
>
> What's the status? Did you give the alternative fix a try? Or should we
> go with the ringbuffer-based fix?
>
pa_stream_begin_write() was simpler indeed. I'll send the updated patch
tomorrow.
Thanks,
--
Darwish
On Mon, 2016-11-28 at 19:23 +0200, Ahmed S. Darwish wrote:
> On Mon, Nov 28, 2016 at 09:04:01AM +0100, David Henningsson wrote:
> > Wouldn't it be better if we had something like:
>
> By better, you mean simpler?
>
> > 1) Call pa_stream_begin_write to get a buffer.
> > 2) If we have half a
Hi!
On Mon, Nov 28, 2016 at 09:04:01AM +0100, David Henningsson wrote:
>
> On 2016-11-28 05:01, Ahmed S. Darwish wrote:
> > Current pacat code reads whatever available from STDIN and writes
> > it directly to the playback stream. A minimal buffer is created
> > for each read operation; no
On 2016-11-28 05:01, Ahmed S. Darwish wrote:
Current pacat code reads whatever available from STDIN and writes
it directly to the playback stream. A minimal buffer is created
for each read operation; no further reads are then allowed unless
earlier read buffer has been fully consumed by a
Current pacat code reads whatever available from STDIN and writes
it directly to the playback stream. A minimal buffer is created
for each read operation; no further reads are then allowed unless
earlier read buffer has been fully consumed by a stream write.
While quite simple, this model breaks