On 04/03/2011 11:20 AM, Kjetil S. Matheussen wrote:
Ouch, there's a bug there! 'tobuffer' must
change position
in case written<bytes_to_write. :-(
I've fixed that.
And also verified that bit conversion works properly on 32 and 64
little-endian architectures. I'm pretty sure the current code is correct
for big-endian archs, too; but let me confirm that after PPC tests
tomorrow and we're ready to roll.
(BTW. How likely is it that 'write'
doesn't write all bytes?)
In my case (1<=bytes_to_write<=4*no_of_channels): very very unlikely.
The Linux pipe is 64k by default and IO_BUFSIZ is 8K bytes (on my 32bit
debian/squeeze - The C standard only specifies the minimum for BUFSIZ).
Since you're writing whole periods worth of samples: It's more likely to
happen with odd bytes/sample and/or odd number of channels. But unless
one is piping directly into some network-socket or is doing similarly
crazy things, I don't think it'll ever happen.
It's different for reading, because the app producing the stream could
fflush() anytime. Anyways, jack-stdio is intended as
instrumentation-tool. Although I'm confident that it works, I do not
recommend using it in a pro-studio or on-stage. It's easy enough to
write a proper JACK client.
Cheers!
robin