Re: partial writes in bse-jack?
- From: Stefan Westerfeld <stefan space twc de>
- To: Tim Janik <timj imendio com>
- Cc: Beasty Crowd <beast gnome org>
- Subject: Re: partial writes in bse-jack?
- Date: Wed, 7 Jun 2006 00:27:01 +0200
On Sun, Jun 04, 2006 at 02:46:38AM +0200, Tim Janik wrote:
> i'm wondering how you could ever encounter partial writes
> in bse-jack. i.e. jack_device_write() being called with a
> full engine block and not enough space in the ringbuffer
> being available to write all the data:
> 1) why is jack_device_write() being called when there
> was no prior jack_device_check_io() that returned TRUE
> or timeout==0?
> 2) why would jack_device_check_io() return TRUE if not
> enough ringbuffer data can be written?
> maybe helpful remarks:
> - bseenginemaster.c:master_poll_check() checks the poll functions
> for the master thread and decides whether data processing is
> neccessary, flagged in bseenginemaster.c:master_need_process.
> - the only current poll function is added via bse_job_add_poll() in
> bsepcmmodule.c: bsepcmmodule.c:bse_pcm_module_poll().
> - in this case, the poll function bse_pcm_module_poll() simply passes
> on the PCM driver's check_io() results 1:1.
> - the engine shouldn't start processing data, if no poll funciton
> returned TRUE or *timeout==0.
> so in theory, if your check_io() function was correctly implemented,
> i'd expect partial writes to never occour. (that being said, it might
> still make sense to guard against them via a Cond or similar, in case
> more poll funcitons are being added in the future.)
I debugged it now, and its simply that the the timeout value computed by
my bse jack driver can become 0 (for instance if there are just 32
samples which miss for writing a whole engine block size to the output
When I stop using the timeout, but instead rely on a newly introduced
public bse_engine_mastere_wakeup() function (right now its private), the
code works as expected. Of course setting timeout to MAX (1,
computedtimeout) also works, but thats not what I want to do, since
timeout based stuff is less reliable when jitter is present than pipe
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan
] [Thread Prev