[linux-audio-dev] pd/k_jack-ish soft-mode patch for jack (was: k_jack v0.0.0.5 andMammut v0.15)
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: >> Yup, replace the set_stop_mode call with: >> snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX); > I'm not able to make that work. Just gets a message about stock audio, > no matter how big buffer it is. But thats not important. Hmm, what's the exact error you get? One thing that will cause you trouble is that audio playback will stop after the first xrun. You have to restart the stream (stop-prepare-start) to recover from an xrun. This is also the source of the longer audible breaks that occur with current JACK's ALSA driver when xruns occur. >> The difference is definitely notable. I've just patched jackd to ignore >> all xruns the way pd does, and yup, I can do all kinds of stuff as a >> normal user (with ./jackd -p 64 -n 27). I'm currently running > Thats very nice. How about an option for jack to ignore xruns then? True, I just posted a patch that does this to jackit-devel. So, so, as I said, competition is a good thing! ;D So thanks for releasing k_jack and helping with the debugging/tracing work. > And, are you absolutely sure its not a bug in alsa, reporting to many > xruns? :) This is very unlikely. The code in alsa-kernel/driver that handles this logic is _very_ robust. I haven't done much driver work, but I've still gone through those functions at least a hundred times, and I bet many other developers have done the same. The common PCM subsystem used by all ALSA low-level drivers is really high-quality code. The fact that all drivers can benefit from this common code library is IMHO one of the biggest benefits ALSA brings! -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Linux Audio Hardware Selection
> > >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > > > On Fri, Jan 24, 2003 at 11:27:12 -0500, Paul Davis wrote: > > because that means we have a config file, which means we need a config > > file parser, which means we need to replicate a bunch of code or link > > against another library. if jackd was a commonly executed command for > > users, i could justify that. as it is, i can't. Steve Harris <[EMAIL PROTECTED]> writes: > What about having a simple config file that is just a set of default > options, eg. /root/.jackrc: > -R -d alsa -d Hammerfall -r 44100 -p 256 > > Then this can be chopped up and prepended to argv[] before being thrown at > the argv parser. > > It doesn't work as well as it might because of the -d thing (so you cant > override the driver easily), but you can still override the rate, number > of periods etc. Why not just distribute an /etc/init.d/jackd script? It would be useful, and such a script can easily read config files with no extra library dependencies in JACK. -- Jack O'Quin Austin, Texas, USA BTW, like everyone else, I like Takashi and Paul's idea of running the JACK engine in-process if libjack finds that no daemon is running.
Re: [linux-audio-dev] amp simulator
On Friday 24 January 2003 05:06, Vishal wrote: > Hi all, >I happen to be both a linux programmer and a guitar freak. Off late > the guitar industry has seen these amp simulators some into being: line6 > POD, Vamp and the likes... i was wondering whether i could build my own > such amp simulator. Could anyone out here suggest me how i can do > this...i mean how do i model amps...the algorithms...any info?? > thanks in advance. > regards, > vishal If you have access to ICMC papers somewhere, here's a reference: Kai Lassfolk 1996. Simulation of electron tube audio circuits. PROCEEDINGS OF THE INTERNATIONAL COMPUTER MUSIC CONFERENCE 1996, Hong Kong University of Science and Technology, Hong Kong, China. IIRC, he used SPKit's waveshaper for the job. http://www.music.helsinki.fi/research/spkit -- Jaakko Prättälä [EMAIL PROTECTED]
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Friday 24 January 2003 19.29, Paul Winkler wrote: > On Fri, Jan 24, 2003 at 11:27:12AM -0500, Paul Davis wrote: > > i've had the same idea. my approach would basically be to have > > libjack try to contact the server. if it fails, then it just > > starts up a thread to run the audio loop, and then instantiate > > the client as an in-process client. > > i must be missing the point. Where does the audio go? isn't jackd > responsible for connecting to alsa? Well, yes - but if the lib fails to find jackd, it can do pretty much anything, instead of just failing. Like trying try to set up some direct audio I/O instead and "fake" jackd. :-) //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! . | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Fri, Jan 24, 2003 at 11:27:12AM -0500, Paul Davis wrote: > i've had the same idea. my approach would basically be to have libjack > try to contact the server. if it fails, then it just starts up a > thread to run the audio loop, and then instantiate the client as an > in-process client. i must be missing the point. Where does the audio go? isn't jackd responsible for connecting to alsa? -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's X-PERVERT WHO LIVES NEXT DOOR! (random hero from isometric.spaceninja.com)
Re: [linux-audio-dev] Linux Audio Hardware Selection
> >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > > because that means we have a config file, which means we need a config > file parser, which means we need to replicate a bunch of code or link > against another library. if jackd was a commonly executed command for > users, i could justify that. as it is, i can't. I would support adding another library. I think both system and user configuration files add a lot to the usability department. BTW, the standalone non-jackd libjack sounds like a very good idea! -- Fernando
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kai Vehmanen wrote: > On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: > > >> This means that you could be having small xruns all the time! Of course, > >> really long breaks are always audible, but shorter ones are sometimes > >> quite subtle. Still, you are losing audio data. > > I guess so. But its not necesarrily very import, at least not for (most > > kinds of) live performance. Is there a quick way to patch pd so that it > > detects xruns? > > Yup, replace the set_stop_mode call with: > > snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX); > > ... where XXX is the buffersize (ie. 64*27=1728). > I'm not able to make that work. Just gets a message about stock audio, no matter how big buffer it is. But thats not important. > The difference is definitely notable. I've just patched jackd to ignore > all xruns the way pd does, and yup, I can do all kinds of stuff as a > normal user (with ./jackd -p 64 -n 27). I'm currently running > ecasound+jackd+freqtweak+qjackconnect as a normal user, with the same > 1.5->39ms latency as with pd, and while there are occasional audible > artifacts, it does indeed work! > Thats very nice. How about an option for jack to ignore xruns then? And, are you absolutely sure its not a bug in alsa, reporting to many xruns? :) --
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Fri, Jan 24, 2003 at 11:27:12 -0500, Paul Davis wrote: > not at all. it would allow programs to be run with no context switch > overhead if they are started alone without jackd, which would be > rather nice. we need to get in-process clients done first, though. Agreed and agreed. > >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > > because that means we have a config file, which means we need a config > file parser, which means we need to replicate a bunch of code or link > against another library. if jackd was a commonly executed command for > users, i could justify that. as it is, i can't. What about having a simple config file that is just a set of default options, eg. /root/.jackrc: -R -d alsa -d Hammerfall -r 44100 -p 256 Then this can be chopped up and prepended to argv[] before being thrown at the argv parser. It doesn't work as well as it might because of the -d thing (so you cant override the driver easily), but you can still override the rate, number of periods etc. - Steve
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Friday 24 January 2003 18.22, Paul Davis wrote: > >> >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > >> > >> because that means we have a config file, which means we need a > >> config file parser, which means we need to replicate a bunch of > >> code or link against another library. if jackd was a commonly > >> executed command for users, i could justify that. as it is, i > >> can't. > > > >Seems like it would be useful for the "no jackd" case, though. (Or > >you'd have to force code changes upon applications anyway.) > > > >For Kobo Deluxe, I just hacked a simple integrated command line > > and config file parser. Inherit the parser class, add your > > argument > > there are plenty of decent config file parsers floating around. > the goal is to avoid JACK requiring other libraries, as much as > possible. Yeah. The point is that it's just two files you throw into your project. Not incredibly sexy, but it works for tiny things that evolve very slowly or not at all. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! . | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---
Re: [linux-audio-dev] Linux Audio Hardware Selection
>> >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) >> >> because that means we have a config file, which means we need a >> config file parser, which means we need to replicate a bunch of >> code or link against another library. if jackd was a commonly >> executed command for users, i could justify that. as it is, i >> can't. > >Seems like it would be useful for the "no jackd" case, though. (Or >you'd have to force code changes upon applications anyway.) > >For Kobo Deluxe, I just hacked a simple integrated command line and >config file parser. Inherit the parser class, add your argument there are plenty of decent config file parsers floating around. the goal is to avoid JACK requiring other libraries, as much as possible. --p
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: >> This means that you could be having small xruns all the time! Of course, >> really long breaks are always audible, but shorter ones are sometimes >> quite subtle. Still, you are losing audio data. > I guess so. But its not necesarrily very import, at least not for (most > kinds of) live performance. Is there a quick way to patch pd so that it > detects xruns? Yup, replace the set_stop_mode call with: snd_pcm_sw_params_set_stop_threshold(handle, sw_params, XXX); ... where XXX is the buffersize (ie. 64*27=1728). The difference is definitely notable. I've just patched jackd to ignore all xruns the way pd does, and yup, I can do all kinds of stuff as a normal user (with ./jackd -p 64 -n 27). I'm currently running ecasound+jackd+freqtweak+qjackconnect as a normal user, with the same 1.5->39ms latency as with pd, and while there are occasional audible artifacts, it does indeed work! Also more common jackd setups like 'jackd -d alsa -p 1024 -n 3' work more reliably this way. But of course, as I noted in my previous message, we are definitely losing samples even though no errors are reported. -- http://www.eca.cx Audio software for Linux!
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote: > >> This means that you could be having small xruns all the time! Of course, > >> really long breaks are always audible, but shorter ones are sometimes > >> quite subtle. Still, you are losing audio data. > >> > >I guess so. But its not necesarrily very import, at least not for (most > >kinds of) live performance. Is there a quick way to patch pd so that it > >detects xruns? > > more to the point, what will it do when it detects one? > At least print "xrun %d\n",n++ to stdout or stderr would be a good start I guess. --
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote: > > they did, I suspect that they'd get similar performance to pd. it > would be interesting to hear how pd works with, say, a period size of > 1024 and a buffer size of 2048 (i.e. 2 mid-size periods) instead of > lots of small periods. > Pd wont run with that setting: kjetism@hensten ~ $ pd -audiobuf 29 -blocksize 1024 couldn't open MIDI input device 1 couldn't open MIDI output device 1 opened 0 MIDI input device(s) and 0 MIDI output device(s). Sample width set to 4 bytes ALSA: set input channels to 12 alsa: set output channels to 10 ALSA lib pcm_hw.c:454:(snd_pcm_hw_start) SNDRV_PCM_IOCTL_START failed: Broken pipe snd_pcm_start: Broken pipe audio I/O stuck... closing audio Cant get it to start with a blocksize higher than 128. --
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
>> This means that you could be having small xruns all the time! Of course, >> really long breaks are always audible, but shorter ones are sometimes >> quite subtle. Still, you are losing audio data. >> >I guess so. But its not necesarrily very import, at least not for (most >kinds of) live performance. Is there a quick way to patch pd so that it >detects xruns? more to the point, what will it do when it detects one?
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kai Vehmanen wrote: > On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: > > > I'm at work now, and we ~only have delta cards. At home I use a built-in > > sound-card on an nforce chipset. But I get nearly the same good > > performance in pd here as at home. So here is delta44 parameters: > > But how do you know you are not losing any data? I mean... > > > kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params > [...] > > stop_threshold: 1811939328 > > ... there seems to be no xrun detection enabled. At least pd-0.36 seems to > set "snd_pcm_sw_params_set_xrun_mode(alsa_device.inhandle, sw_params, > SND_PCM_XRUN_NONE);". > > This means that you could be having small xruns all the time! Of course, > really long breaks are always audible, but shorter ones are sometimes > quite subtle. Still, you are losing audio data. > I guess so. But its not necesarrily very import, at least not for (most kinds of) live performance. Is there a quick way to patch pd so that it detects xruns? --
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: > I'm at work now, and we ~only have delta cards. At home I use a built-in > sound-card on an nforce chipset. But I get nearly the same good > performance in pd here as at home. So here is delta44 parameters: But how do you know you are not losing any data? I mean... > kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params [...] > stop_threshold: 1811939328 ... there seems to be no xrun detection enabled. At least pd-0.36 seems to set "snd_pcm_sw_params_set_xrun_mode(alsa_device.inhandle, sw_params, SND_PCM_XRUN_NONE);". This means that you could be having small xruns all the time! Of course, really long breaks are always audible, but shorter ones are sometimes quite subtle. Still, you are losing audio data. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] Linux Audio Hardware Selection
On Friday 24 January 2003 17.27, Paul Davis wrote: [...] > >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) > > because that means we have a config file, which means we need a > config file parser, which means we need to replicate a bunch of > code or link against another library. if jackd was a commonly > executed command for users, i could justify that. as it is, i > can't. Seems like it would be useful for the "no jackd" case, though. (Or you'd have to force code changes upon applications anyway.) For Kobo Deluxe, I just hacked a simple integrated command line and config file parser. Inherit the parser class, add your argument variables and implement a function that registers the variables. Then tell it to read your config file and/or hand it argc + argv. You can have default values and check whether default values were overidden, and there's support for integers, floats, switches and strings. Unfortunately, it's in C++, though the actual code is mostly C style, and shouldn't be too hard to port. (The key registering won't look as sexy, but that's no major issue.) Licence is LGPL, like most of my engine/lib sort of stuff. I don't have it as a separate package, but that can be arranged if there's interest. //David Olofson - Programmer, Composer, Open Source Advocate .- The Return of Audiality! . | Free/Open Source Audio Engine for use in Games or Studio. | | RT and off-line synth. Scripting. Sample accurate timing. | `---> http://olofson.net/audiality -' --- http://olofson.net --- http://www.reologica.se ---
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
>Paul Davis wrote: > >> JACK is specifically designed not to allow latency jitter. you can't >> properly sync audio+video with latency jitter, because the software >> cannot know for sure when the audio it generates will actually become >> audible. > >Why not ? > >If B = buffer size, Fs = sample frequency, T = start time, and the >buffer if pre-filled before starting, then the k-th sample will reach the buffer may have been prefilled. but the problem arises when you've missed some period deadlines. you no longer have a full buffer and you don't know how much of the buffer you are filling if you do it 1 period at a time. if you ask how much total space is available, then that will work, but this then requires dynamic buffer resizing inside the software, or alternatively, the software has to use buffers sized to hold the entire hardware buffer, which is very wasteful. using the process-in-period-sized-blocks model, if you missed several period deadlines, then the "last" audio you deliver as you finish catching up has longer latency than the ones you processed at the beginning. this is why JACK uses ASIO's model of 2 periods per buffer by default, and under RT operation it doesn't allow you to miss any deadlines. --p
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote: > >Hmm, this is quite interesting. With a period size of 64 frames, > >you'd get quite a lot of context switches with jackd. Kjetil, does > >your ipc-lib make the context switches this often? > > > >Another interesting this is how this high interrupt frequency affects > >scheduling of (non-root) processes. I'd guess it could have a notable > >impact on reliability... have to try this later today with jackd. > > i have been unable to reliably run jackd with a period size of 64 > frames on my dual CPU system. you may recall that i spent considerable > time trying to track down what was preventing it from happening, to no > avail. something in the kernel appears to prevent reliable scheduling > at this level. that is, jackd is not reliably woken by the kernel when > the audio interface interrupt arrives, or rather, its not reliably > woken in time to properly service the interrupt. and if not that, then > the kernel fails to reliably and promptly schedule the other > clients. with only 2 periods per buffer, these scheduling errors are > fatal. it will be interesting to see how 2.5 performs in this regard. > > pd (with the configuration kjetil has shown) would be unaffected by > this unless it affected 27 periods in a row, which is rather > unlikely. > Let me just say that I have just tested to see if k_jack could handle lower latencies than 39msec running one freqtweak. And indeed it does. 9 msecs seems to work fine (no overruns), even when compiling QT3.1.1 in the background. 4 msecs works too, but overruns happens when doing X things. The machine this was tested on is an Asus a7n266-vm with xp2100 processor, wd 8mb cache ide HD, 512 mb memory, inboard geforce2 gfx card and delta 44 soundcard. kjetism@hensten ~ $ more /proc/version Linux version 2.4.18-18.7.x ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-112)) #1 Wed Nov 13 20:29:30 EST 2002 On the other hand, 39msec does not work very fine on an other machine. It is a 733mzh piii with asus cucl2 (or something) mainboard, 256 mb memory, matrox g550 gfx card, samsung ide HD and delta 44 soundcard. I _suspect_ its the GFX card (or driver) thats causing this. kjetism@olivier ~ $ more /proc/version Linux version 2.4.18-17.7.x ([EMAIL PROTECTED]) (gcc version 2.96 2731 (Red Hat Linux 7.3 2.96-112)) #1 Tue Oct 8 13:33:14 EDT 2002 kjetism@olivier ~ $ --
Re: [linux-audio-dev] Linux Audio Hardware Selection
>At Fri, 24 Jan 2003 08:09:44 -0500, >Paul Davis wrote: >> >> the other alternative that many of us here like rather a lot is JACK >> (http://jackit.sf.net/), which provides a different model: data >> sharing between applications, shared access to hardware, >> sample-synchronous execution of all applications, and no hardware >> parameters to be configured. it sits on top of ALSA (and potentially >> other similar hardware abstractions). > >what i've thought of is to make libjack runnable as standalone without >jack server. i know it sounds useless for serious purpose. not at all. it would allow programs to be run with no context switch overhead if they are started alone without jackd, which would be rather nice. we need to get in-process clients done first, though. imagine: your program can run in either mode - networked to other applications and sharing the audio interface, or running with high efficiency all by itself. all this with no code changes to your application! >but, at least, people can write the application using a simple API, >and have possiblity to debug in different environment. i've had the same idea. my approach would basically be to have libjack try to contact the server. if it fails, then it just starts up a thread to run the audio loop, and then instantiate the client as an in-process client. >for example, in the standalone mode, libjack will initialize the >necessary hardware setup silenty according to the config file, so that >in the application you don't need to set up the nasty things. >(btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) because that means we have a config file, which means we need a config file parser, which means we need to replicate a bunch of code or link against another library. if jackd was a commonly executed command for users, i could justify that. as it is, i can't. --p
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
Paul Davis wrote: > JACK is specifically designed not to allow latency jitter. you can't > properly sync audio+video with latency jitter, because the software > cannot know for sure when the audio it generates will actually become > audible. Why not ? If B = buffer size, Fs = sample frequency, T = start time, and the buffer if pre-filled before starting, then the k-th sample will reach the DA converter at T + (k + B) / Fs. The time the sample was computed doesn't matter. -- Fons Adriaensen Alcatel Space
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote:
> no, there's likely not much latency jitter in pd either. after the
> first 27 periods are filled (which happens in about 39ms), every chunk
> of audio delivered by pd to the hardware will be output by the
> hardware about 38ms later. the jitter is limited to about 1.45ms,
> assuming that pd is roughly keeping up with the hardware. of course,
But there's no way a normal user-space can reliably wake-up every 1.45ms
and manages do finish i/o for next period. The application is bound to
late, much of the time. This is not necessarily fatal if the application
is able to catch up. This is precisely the reason why you can get very
reliably processing with ecasound using -z:intbuf option (maximize use of
soundcard hw buffering).
> However, as Kai pointed out, nobody runs JACK with -p 64 -n 27, and if
> they did, I suspect that they'd get similar performance to pd. it
Actually, with current jackd you cannot use -p 64 -n 27, as it will
throw the "delay of %.3f usecs exceeds estimated spare time of %.3f;
restart ..." error and stop the alsa_driver. I made a patch that bypasses
this check and managed to get jackd running with -p 64 -n 27. And indeed,
it runs reasonably well on my laptop (normal user space), but I still
get xrun from ALSA. Below are some stats. As you can see from the
'delay' values, the latency jitter is considerable, even though the test
machine was not doing anything else than jackd+ecasound playback.
--cut--
[xxx]$ cat /proc/asound/card0/pcm0p/sub0/{sw_params,hw_params,status}
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 0
stop_threshold: 1728
silence_threshold: 0
silence_size: 0
boundary: 1811939328
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1
state: RUNNING
trigger_time: 1043423501.808278
tstamp : 1043423507.253736
delay : 1204
avail : 524
avail_max : 704
-
hw_ptr : 240268
appl_ptr: 241472
[xxx]$ cat /proc/asound/card0/pcm0p/sub0/{sw_params,hw_params,status}
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 64
xfer_align: 64
start_threshold: 0
stop_threshold: 1728
silence_threshold: 0
silence_size: 0
boundary: 1811939328
access: MMAP_INTERLEAVED
format: S16_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 64
buffer_size: 1728
tick_time: 1
state: RUNNING
trigger_time: 1043424884.923610
tstamp : 1043424886.101041
delay : 1678
avail : 50
avail_max : 1728
-
hw_ptr : 51762
appl_ptr: 53440
--cut--
--
http://www.eca.cx
Audio software for Linux!
Re: [linux-audio-dev] Linux Audio Hardware Selection
At Fri, 24 Jan 2003 08:09:44 -0500, Paul Davis wrote: > > the other alternative that many of us here like rather a lot is JACK > (http://jackit.sf.net/), which provides a different model: data > sharing between applications, shared access to hardware, > sample-synchronous execution of all applications, and no hardware > parameters to be configured. it sits on top of ALSA (and potentially > other similar hardware abstractions). what i've thought of is to make libjack runnable as standalone without jack server. i know it sounds useless for serious purpose. but, at least, people can write the application using a simple API, and have possiblity to debug in different environment. for example, in the standalone mode, libjack will initialize the necessary hardware setup silenty according to the config file, so that in the application you don't need to set up the nasty things. (btw, why jackd doesn't read /etc/jackrc or ~/.jackrc ?) Takashi
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
On Friday 24 January 2003 10:19, Paul Davis wrote: > i don't of any h/w that has a 2.5 second buffer!! AudioScience cards do -- some of them sport up to 8 MB buffers (dynamically divided among the various pcm streams). But then , low-lat is not exactly a pressing design goal there... :) Cheers! |-| | Frederick F. Gleason, Jr. | Salem Radio Labs | | Voice: 1-(540)-341-2880 | 87 Lee Highway, Suite 11 | |FAX: 1-(540)-341-7176|Warrenton, VA 20188| |-| | When your client's hopping mad,| | Put his picture in the ad. | | If he still should prove refractory, | | Add a picture of his factory. | | -- The Advertising Agency Song | |-|
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
>Hmm, this is quite interesting. With a period size of 64 frames, >you'd get quite a lot of context switches with jackd. Kjetil, does >your ipc-lib make the context switches this often? > >Another interesting this is how this high interrupt frequency affects >scheduling of (non-root) processes. I'd guess it could have a notable >impact on reliability... have to try this later today with jackd. i have been unable to reliably run jackd with a period size of 64 frames on my dual CPU system. you may recall that i spent considerable time trying to track down what was preventing it from happening, to no avail. something in the kernel appears to prevent reliable scheduling at this level. that is, jackd is not reliably woken by the kernel when the audio interface interrupt arrives, or rather, its not reliably woken in time to properly service the interrupt. and if not that, then the kernel fails to reliably and promptly schedule the other clients. with only 2 periods per buffer, these scheduling errors are fatal. it will be interesting to see how 2.5 performs in this regard. pd (with the configuration kjetil has shown) would be unaffected by this unless it affected 27 periods in a row, which is rather unlikely. note, however, that jack can be used with this same configuration. i just don't know anyone who would want the results: high interrupt load, and unacceptably large latency for live performance - the worst of both worlds :) --p
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kai Vehmanen wrote: > > this is still pretty long, and as you note, pd is not subject to > > per-period time limits with this configuration. it can take too long > > on up to 26 of 27 periods before there is an xrun. > > Hmm, this is quite interesting. With a period size of 64 frames, > you'd get quite a lot of context switches with jackd. Kjetil, does > your ipc-lib make the context switches this often? > Yes it does. --
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
>> I'm quite sure you get much more reliable performance this way, although >> JACK doesn't take advantage of multip-period buffer configurations very >> well. And this has its reasons. With a setup like shown above, you either >> get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter >> (latency varies between 1.45ms->2500ms). Both are something we'd _really_ >> want to avoid. >> >> Because of the above reasons, JACK is designed for two or three >> period operation (-n 2 or -n 3). This way we can achieve both low >> latency and avoid latency jitter. We could improve reliability by >> sacrificing one or both of these goals, but for many of the use scenarios >> we are aiming at, this is simply not acceptable. >> > >Pd does not run with 2500ms standard latency, thats for sure. So if >your theory is correct, and it probably gives latency jitter, it >must do a pretty good job at making it unhearable. no, there's likely not much latency jitter in pd either. after the first 27 periods are filled (which happens in about 39ms), every chunk of audio delivered by pd to the hardware will be output by the hardware about 38ms later. the jitter is limited to about 1.45ms, assuming that pd is roughly keeping up with the hardware. of course, if its not keeping up, then sure, the latency can jitter anywhere from 1.45ms to the entire buffer, but i doubt that this is true. theoretically its possible though. my guess is that a running instance of pd with this h/w setup sees latency jitter between about 1.45ms and 8ms (4 periods). >Wouldnt it be a good idea to have an option for jack to hide latency >jitter? Or is it to much work (hacking) with the design model? JACK is specifically designed not to allow latency jitter. you can't properly sync audio+video with latency jitter, because the software cannot know for sure when the audio it generates will actually become audible. pd, by contrast, allows significant latency jitter but in all likelihood doesn't cause it to wobble all that much. However, as Kai pointed out, nobody runs JACK with -p 64 -n 27, and if they did, I suspect that they'd get similar performance to pd. it would be interesting to hear how pd works with, say, a period size of 1024 and a buffer size of 2048 (i.e. 2 mid-size periods) instead of lots of small periods. --p
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Paul Davis wrote: >>> period_size: 64 >>> buffer_size: 1728 > >So I guess this explains a lot. This equals to running jackd > >with "-p 64 -n 27" (and not as root or otherwise it will throw clients Well, this is still true. >>well. And this has its reasons. With a setup like shown above, you either >>get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter > not that large. you don't multiply the period size by the buffer size > and the 1000 is extraneous too. the maximum latency is 1728/44100 = > 39ms, i think. i don't of any h/w that has a 2.5 second buffer!! Arrghghthghhg! :D 2500ms would have made a nice pro-jack argument, though.;) So the correct one is the 64*27/44100*1000=39ms you mention. > this is still pretty long, and as you note, pd is not subject to > per-period time limits with this configuration. it can take too long > on up to 26 of 27 periods before there is an xrun. Hmm, this is quite interesting. With a period size of 64 frames, you'd get quite a lot of context switches with jackd. Kjetil, does your ipc-lib make the context switches this often? Another interesting this is how this high interrupt frequency affects scheduling of (non-root) processes. I'd guess it could have a notable impact on reliability... have to try this later today with jackd. -- http://www.eca.cx Audio software for Linux!
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kai Vehmanen wrote: > On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: > > >> What does "cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params" output > > I'm at work now, and we ~only have delta cards. At home I use a built-in > > sound-card on an nforce chipset. But I get nearly the same good > > performance in pd here as at home. So here is delta44 parameters: > > Could you also send an output of pcm0[cp]/sub0/status...? > Anyway, this is very good info. > kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more /proc/asound/card0/pcm0c/sub0/hw_params access: RW_INTERLEAVED format: S32_LE subformat: STD channels: 12 rate: 44100 (44100/1) period_size: 64 buffer_size: 1728 tick_time: 1953 kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more /proc/asound/card0/pcm0c/sub0/sw_params tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 64 xfer_align: 64 start_threshold: 1811939328 stop_threshold: 1811939328 silence_threshold: 0 silence_size: 0 boundary: 1811939328 kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more /proc/asound/card0/pcm0p/sub0/hw_params access: RW_INTERLEAVED format: S32_LE subformat: STD channels: 10 rate: 44100 (44100/1) period_size: 64 buffer_size: 1728 tick_time: 1953 kjetism@hensten /div/notam02/site/qt-x11-free-3.1.1 $ more /proc/asound/card0/pcm0p/sub0/sw_params tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 64 xfer_align: 64 start_threshold: 1811939328 stop_threshold: 1811939328 silence_threshold: 0 silence_size: 0 boundary: 1811939328 > > kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params > [...] > > period_size: 64 > > buffer_size: 1728 > > So I guess this explains a lot. This equals to running jackd > with "-p 64 -n 27" (and not as root or otherwise it will throw clients > out if they miss one 64 frame deadline). > > I'm quite sure you get much more reliable performance this way, although > JACK doesn't take advantage of multip-period buffer configurations very > well. And this has its reasons. With a setup like shown above, you either > get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter > (latency varies between 1.45ms->2500ms). Both are something we'd _really_ > want to avoid. > > Because of the above reasons, JACK is designed for two or three > period operation (-n 2 or -n 3). This way we can achieve both low > latency and avoid latency jitter. We could improve reliability by > sacrificing one or both of these goals, but for many of the use scenarios > we are aiming at, this is simply not acceptable. > Pd does not run with 2500ms standard latency, thats for sure. So if your theory is correct, and it probably gives latency jitter, it must do a pretty good job at making it unhearable. Wouldnt it be a good idea to have an option for jack to hide latency jitter? Or is it to much work (hacking) with the design model? --
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 and Mammut v0.15
>> period_size: 64 >> buffer_size: 1728 > >So I guess this explains a lot. This equals to running jackd >with "-p 64 -n 27" (and not as root or otherwise it will throw clients >out if they miss one 64 frame deadline). > >I'm quite sure you get much more reliable performance this way, although >JACK doesn't take advantage of multip-period buffer configurations very >well. And this has its reasons. With a setup like shown above, you either >get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter not that large. you don't multiply the period size by the buffer size and the 1000 is extraneous too. the maximum latency is 1728/44100 = 39ms, i think. i don't of any h/w that has a 2.5 second buffer!! this is still pretty long, and as you note, pd is not subject to per-period time limits with this configuration. it can take too long on up to 26 of 27 periods before there is an xrun. this configuration is not even vaguely equivalent to the one JACK is typically run with. its not a similar test at all. --p
Re: [Jackit-devel] Re: [PD-announce] Re: [linux-audio-dev] ANN:k_jack v0.0.0.5 and Mammut v0.15
On Fri, 24 Jan 2003, Kjetil S. Matheussen wrote: >> What does "cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params" output > I'm at work now, and we ~only have delta cards. At home I use a built-in > sound-card on an nforce chipset. But I get nearly the same good > performance in pd here as at home. So here is delta44 parameters: Could you also send an output of pcm0[cp]/sub0/status...? Anyway, this is very good info. > kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params [...] > period_size: 64 > buffer_size: 1728 So I guess this explains a lot. This equals to running jackd with "-p 64 -n 27" (and not as root or otherwise it will throw clients out if they miss one 64 frame deadline). I'm quite sure you get much more reliable performance this way, although JACK doesn't take advantage of multip-period buffer configurations very well. And this has its reasons. With a setup like shown above, you either get a huge latency (64*1728/44100*1000=2500ms), or you get latency jitter (latency varies between 1.45ms->2500ms). Both are something we'd _really_ want to avoid. Because of the above reasons, JACK is designed for two or three period operation (-n 2 or -n 3). This way we can achieve both low latency and avoid latency jitter. We could improve reliability by sacrificing one or both of these goals, but for many of the use scenarios we are aiming at, this is simply not acceptable. -- http://www.eca.cx Audio software for Linux!
Re: [linux-audio-dev] amp simulator
On Thu, Jan 23, 2003 at 07:10:47 +, Mark Knecht wrote: > Vishal, >I think there was some work done in the last few months on this. > Check the archives. I think Steve Harris was one of the participants. I > know they were working on modeling tubes, and I seem to remember someone > talking about playing their guitar through it. Tim Goetze was the main contributor, search for his postings to this list from last year. - Steve
Re: [linux-audio-dev] python sound
On Fri, Jan 24, 2003 at 09:57:39 +, david casal wrote: > > http://www.eca.cx/eca_links.htm > > Hm. Broken? Try .html - Steve
Re: [linux-audio-dev] Linux Audio Hardware Selection
>I was looking for a good, up-to-date documentation pointer upon software featu >res provided by alsa. But I'm new to this architecture and I might be "intoxic >ated" by some kernel streaming architectures : is there a kind of hardware ab >straction with ALSA, e.g. features that are managed by the software at usr or >kernel level, in a +/-transparent way, when the HW does not provide them ? yes, its called alsa-lib. its big, its bold, and to some people its beautiful. >My understanding is that Alsa does not provide multiple device open (a second >open can be blocking, or return with an error, but won't succeed, as no sw mix >ing is available). that's correct right at this very moment in time. however, the mythical "mix" ALSA PCM "plugin" provides multi-open-without-h/w-support by streaming data to a server called "aserver". at this time, the mix plugin is not part of the ALSA source base. its far from clear that anyone is doing any work on it. >is there anything that can be emulated by alsa on user request, when the hw ca >nnot ? (for instance frequency change, frame conversion (n channels to m chan >nels) etc...). all of it. the other alternative that many of us here like rather a lot is JACK (http://jackit.sf.net/), which provides a different model: data sharing between applications, shared access to hardware, sample-synchronous execution of all applications, and no hardware parameters to be configured. it sits on top of ALSA (and potentially other similar hardware abstractions). --p
Re: [linux-audio-dev] sooperlooper goes PD
On Thu, 2003-01-23 at 21:23, Bob Ham wrote: > On Thu, 2003-01-23 at 18:02, François Déchelle wrote: > > > > I'm guessing that Paul was wondering how you tell the LADSPA plugin what > > > jMax patch to load. Well, thats what I'm wondering anyway ;) > > > > If the patch is included in the .c, then you tell it when building the > > plugin. > > Could you not do something similar to the vst plugin? Ie, have an > LADSPA_JMAX_PATH, or something, that has directories containing patches, > and have the ladspa .so build its list of plugins from scanning these > directories? I don't know anything about jmax; is there something that > stops this from working? > > Bob > > But even using this, you still have to pass to the plugin the name of the patch to be loaded, in case there are several patches (i.e. .jmax files) in the LADSPA_JMAX_PATH directories ? fd
Re: [PD-announce] Re: [linux-audio-dev] ANN: k_jack v0.0.0.5 andMammut v0.15
On Thu, 23 Jan 2003, Kai Vehmanen wrote: > > k_jack performs okey. You dont have to run things with realtime priority. > > What does "cat /proc/asound/card0/pcm0[cp]/sub0/[hs]w_params" output > while you are running k_jack? This information should help us understand > the benefits of k_jack over current jackd. > I'm at work now, and we ~only have delta cards. At home I use a built-in sound-card on an nforce chipset. But I get nearly the same good performance in pd here as at home. So here is delta44 parameters: kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more hw_params access: RW_INTERLEAVED format: S32_LE subformat: STD channels: 12 rate: 44100 (44100/1) period_size: 64 buffer_size: 1728 tick_time: 1953 kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ more sw_params tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 64 xfer_align: 64 start_threshold: 1811939328 stop_threshold: 1811939328 silence_threshold: 0 silence_size: 0 boundary: 1811939328 kjetism@hensten /proc/asound/card0/pcm0c/sub0 $ kjetism@hensten /proc/asound/card0/pcm0p/sub0 $ more hw_params access: RW_INTERLEAVED format: S32_LE subformat: STD channels: 10 rate: 44100 (44100/1) period_size: 64 buffer_size: 1728 tick_time: 1953 kjetism@hensten /proc/asound/card0/pcm0p/sub0 $ more sw_params tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 64 xfer_align: 64 start_threshold: 1811939328 stop_threshold: 1811939328 silence_threshold: 0 silence_size: 0 boundary: 1811939328 kjetism@hensten /proc/asound/card0/pcm0p/sub0 $ Pd is v0.35, running as normal user, no special hardware options except "-alsa". --
Re: [linux-audio-dev] New relase of ZynAddSubFX (1.0.5)
Nasca, Hi. I sent you a message before but didn't get a reply. I very much like the sound of your synth, but I work in a Jack oriented environment. When will you add Jack support? I hope you will. Thanks, Mark On Fri, 2003-01-24 at 10:01, Nasca Paul wrote: > Hi. > Today I relased ZynAddSubFX 1.0.5. > It is a powerfull software synthesizer for Linux. > > News: > - The bug that crashed ZynAddSubFX if you change > some effect parameters, it is realy removed (I forgot > to update the file before upload) > - Other bugfixes and code clean-ups > - Added a Global Filter to SubSynth > - Added keyresponse limits to Part > - Added presets to Effects > - The fade is smaller on high frequecy content > and larger on low frequecies; so you'll don't hear > starting clicks on basses and audible fadeins on > higher pitched sounds > - Added tunnings to Reverb: you can choose > Random of Freeverb > > If you do something interesting with ZynAddSubFX (nice > instruments, for example), please send me parameter > files(master settings - *.mas_zyn or instruments - > *.ins_zyn or banks) and (perhaps) midi files. > > You can download it at: > http://zynaddsubfx.sourceforge.net > or > http://sourceforge.net/projects/zynaddsubfx > > > > > __ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com
RE: [linux-audio-dev] Linux Audio Hardware Selection
Hi all, I was looking for a good, up-to-date documentation pointer upon software features provided by alsa. But I'm new to this architecture and I might be "intoxicated" by some kernel streaming architectures : is there a kind of hardware abstraction with ALSA, e.g. features that are managed by the software at usr or kernel level, in a +/-transparent way, when the HW does not provide them ? My understanding is that Alsa does not provide multiple device open (a second open can be blocking, or return with an error, but won't succeed, as no sw mixing is available). is there anything that can be emulated by alsa on user request, when the hw cannot ? (for instance frequency change, frame conversion (n channels to m channels) etc...). How would you implement such thing ? With a kind of abstraction layer daemon, that exports the same api but perform missing hw features ? Could the LADSPA plugin architecture be a solution to implement multiple device open ? tx Marc.
[linux-audio-dev] New relase of ZynAddSubFX (1.0.5)
Hi. Today I relased ZynAddSubFX 1.0.5. It is a powerfull software synthesizer for Linux. News: - The bug that crashed ZynAddSubFX if you change some effect parameters, it is realy removed (I forgot to update the file before upload) - Other bugfixes and code clean-ups - Added a Global Filter to SubSynth - Added keyresponse limits to Part - Added presets to Effects - The fade is smaller on high frequecy content and larger on low frequecies; so you'll don't hear starting clicks on basses and audible fadeins on higher pitched sounds - Added tunnings to Reverb: you can choose Random of Freeverb If you do something interesting with ZynAddSubFX (nice instruments, for example), please send me parameter files(master settings - *.mas_zyn or instruments - *.ins_zyn or banks) and (perhaps) midi files. You can download it at: http://zynaddsubfx.sourceforge.net or http://sourceforge.net/projects/zynaddsubfx __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Re: [linux-audio-dev] python sound
Hello Kai, Thanks go to you, Guenter et al for answers on this! much more goin' on in pysound world than I thought! On Fri, 24 Jan 2003, Kai Vehmanen wrote: > http://www.eca.cx/ Wow. > http://www.eca.cx/eca_links.htm Hm. Broken? getting: 'The resource requested /eca_links.htm cannot be found.' d david casal --0+ --- [EMAIL PROTECTED] --9+ --- ecdc.dyndns.org/dc--)+
