On Fri, 1 Apr 2011, Robin Gareus wrote:
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).
@Kjetil:
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).
jack_capture writes blocks at the time:
int bytes_to_write=frames*num_channels*2;
{
int i;
int writeplace=0;
for(i=0;i<frames*num_channels;i++){
int d = (int) rint(buffer[i]*32767.0);
tobuffer[writeplace++] = (unsigned char) (d&0xff);
tobuffer[writeplace++] = (unsigned char) (((d&0xff00)>>8)&0xff);
}
}
{
int fd=fileno(stdout);
while(bytes_to_write > 0){
int written=write(fd,tobuffer,bytes_to_write);
if(written==-1){
fprintf(stderr,"Error writing to stdout.\n");
break;
}
bytes_to_write -= written;
}
}
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.
Thanks.