Hi,
I had some time to do testing during holiday. I had several computers
ranging from 300MHz to 2.8GHz and all based on Slackware 9.1 and ALSA from
0.9.6 to 1.0.1 (found 1.0.1 yesterday..). I patched the 2.4.23 kernel with
the Andrew Morton's low-latency patch (with control via sysctl).
The
I need a system where the starting of the playback/recording has systematic
(and minimal) delays.
Now I have read some faqs and, if I have understood right, it is not
possible to have systematic delays and this all is the question of
latencies. The system has 2.4.20-8 kernel without any
Hi,
I need a system where the starting of the playback/recording has systematic
(and minimal) delays.
When I do a test with two computers (with accurate GPS clocks) running two
shell script:
Script in computer 1:
-
STARTTIME1=`date +%y%m%d%H%M%S%N`
echo 'Recording started
Jaroslav,
thanks!
At 23:40 22.10.2003 +0200, Jaroslav Kysela wrote:
Simply use three byte S24_LE3 format...
To be exact: S24_3LE works fine.
^^^
//panu
---
This SF.net email is sponsored by OSDN developer relations
Here's
Hi,
does anybody know any command line utility that would strip the additional
bits from recordings? My software configuration doesn't support 24 bit
recording (or is this a common ALSA problem?), but my sound hardware does
and I would like to acquire all the bits. The only way to do this is
The solution was simple: update to ALSA 0.9.6. Special thanks go to Anders
Torger - he told that there was a bug in the 0.9.4! If I just had waited
one month and started with version 0.9.6 ... I would spend only a minute to
get ADAT capture working compared to these couple of weeks.
I suppose
Hi!
Shortly: everything else works but ADAT capture fails.
This is my first time playing with ALSA, so there might be an easy
solution... Anyway, I have now tried one week with two different computers
and installations without results.. so, You are my last hope!
The sound card is:
# cat
