On Apr 1, 2011, at 2:13 PM, Kjetil S. Matheussen wrote:
Sure, this is un*x. There's always at least two ways to get the job done :-)
> However, for piping jack-stdout just got options for 24 bits, while jack_capture still only supports 16 bits.
See the announce from today. jack-stdio supports 8/16/24/32 bit integer, both big and little endian, as well as 32 bit float (both native-endian as well as swapped endianess).
Does jack_capture buffer the [processed] data before I/O? jack-stdio does not.
jack-stdin/out reads/writes one sample at a time, and thus is relatively heavy on the CPU
(3-5% on a 2GHz machine - quite a lot for a such a small tool).
> The reason why jack_capture lags a bit behind here is probably because jack_capture used code from jack-stdout to implement writing to stdout. :-)
Before you look into merging it: I just have spotted a bug with endianess for PPC/ big-endian architectures.
all the #ifdef __BIG_ENDIAN__ code can go away: The compiler (at least gcc) does swap
constants 0x00ff <> 0xff00 and indices for uint8_t.
I'll have access to a PPC machine on Monday and will fix and test then.
Linux-audio-user mailing list