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 _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
