1 Apr
2011
1 Apr
'11
2:13 p.m.
Peder Hedlund:
This command does exactly the same:
jack_capture -c 2 -ws | oggenc -R 44100 -B 16 -C 2 - -o file.ogg
although this command is strongly preferable (no bits lost in piping):
jack_capture -c 2 -f ogg file.ogg
However, for piping jack-stdout just got options for 24 bits, while
jack_capture still only supports 16 bits. 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. :-)
On 04/01/2011 04:34 AM, Robin Gareus wrote:
Not that I don't appreciate the work behind jack-stdin/out (and I
wouldn't mind having them included in the jack toolset) but these
things can also be performed using for instance mplayer and
jack_capture :
sox cdda.wav -t wav - tremolo 5 100 | mplayer -cache 26000 -ao jack -
and
jack_capture --channels 2 --port system:playback_1 --port system:playback_2 \
-ws | oggenc -R 44100 -B 16 -C 2 - -o file.ogg
> Robin Gareus wrote:
>
>> Hya,
>>
>> I've just brought jack-stdout up to scratch.
This should definitely be a part of the jack default toolset. 
1 Apr
1 Apr
3:14 p.m.
New subject: jack-stdio 1.1 - was [ANN] jack-stdout 1.0
On Apr 1, 2011, at 2:13 PM, Kjetil S. Matheussen wrote:
Peder Hedlund:
This command does exactly the same:
jack_capture -c 2 -ws | oggenc -R 44100 -B 16 -C 2 - -o file.ogg
although this command is strongly preferable (no bits lost in piping):
jack_capture -c 2 -f ogg file.ogg
Sure, this is un*x. There's always at least two ways to get the job done :-)
On 04/01/2011 04:34 AM, Robin Gareus wrote:
Not that I don't appreciate the work behind jack-stdin/out (and I
wouldn't mind having them included in the jack toolset) but these
things can also be performed using for instance mplayer and
jack_capture :
sox cdda.wav -t wav - tremolo 5 100 | mplayer -cache 26000 -ao jack -
and
jack_capture --channels 2 --port system:playback_1 --port system:playback_2 \
-ws | oggenc -R 44100 -B 16 -C 2 - -o file.ogg
> Robin Gareus wrote:
>
>> Hya,
>>
>> I've just brought jack-stdout up to scratch.
This should definitely be a part of the jack default toolset. 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).
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.
Cheers!
robin
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
3 Apr
3 Apr
11:14 a.m.
New subject: jack-stdio 1.1 - was [ANN] jack-stdout 1.0
On Fri, 1 Apr 2011, Robin Gareus wrote:
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;
}
}
Thanks.
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).
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.
11:20 a.m.
New subject: jack-stdio 1.1 - was [ANN] jack-stdout 1.0
On Sun, 3 Apr 2011, Kjetil S. Matheussen wrote:
{
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;
}
}
Ouch, there's a bug there! 'tobuffer' must change position
in case written<bytes_to_write. :-(
(BTW. How likely is it that 'write' doesn't write all bytes?)
7:04 p.m.
New subject: jack-stdio 1.1 - was [ANN] jack-stdout 1.0
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
4984
days inactive
4986
days old
linux-audio-user@lists.linuxaudio.org
4 comments
2 participants
participants (2)
-
Kjetil S. Matheussen -
Robin Gareus