From: Richard C. <spa...@ec...> - 2007-08-25 09:07:04
|
I installed Ingo Molnar's patch, finally, and set up everything as best = I = could. I looked at /proc/interrupts to learn that my sound card was on = = IRQ 5, then I set the IRQ-5 thread to run at realtime priority 99. Then I started jackd at realtime priorty 90, and the result: No period = = size smaller than 512 results in less than one xrun every few seconds. = = Using 512 seems to cause a few each minute, and is what I would call = "borderline useable." So I decided to see what ZynAddSubFX could do without Jack. I had to = recompile it with OSS support, because it's ALSA support is limited to = only the ALSA sequencer API. It uses the OSS API for ALSA sound, and I = = don't blame it. I've written a few tiny OSS programs, but never an ALSA= = one because the documentation is a bitch. It's all like "use alsalib" a= nd = I'm all like "but I don't want to write my program in C." Why does = everyone act as if C is the only programming language in the world, and = as = long as they provide a C API, they've provided an API? Anyway, you won't believe this: (and for good reason) pj@sucks:~/zynaddsubfx$ zynaddsubfx -l default.xmz -o 16384 -A -r 44100 = -b = 2 ZynAddSubFX - Copyright (c) 2002-2005 Nasca Octavian Paul Compiled: Aug 24 2007 23:30:28 This program is free software (GNU GPL v.2) and it comes with ABSOLUTELY NO WARRANTY. Sound Buffer Size =3D 2 samples Internal latency =3D 0.0 ms ADsynth Oscil.Size =3D 16384 samples Master file loaded. No realtime priority, a buffer size of two, and it still played = flawlessly. The "ADsynth Oscil.Size" isn't related to sound buffering, = = but to the size of the samples used for synthesis. It actually works mu= ch = better using the default setting (which I think is 512 or so) but I = increased it just to be sure it had nothing to do with audio buffering. = = If it did, I'd experience a latency of 1/3 of a second with the above = settings, but I don't. It only works for my instruments, because my instruments are bloody = simple. It sounds like shit if I try anyone else's instruments. Playin= g = with one if the instruments that come with it, I can play one or two not= es = just fine, but if I try a three note chord, what I hear is mostly noise.= = Using a period size of 44 samples seems to mostly clear that up. ...and that's a problem. It isn't possible to specify a buffer size of = 44 = using the OSS API, and so when ZynAddSubFX accepts this as a buffer size= , = clearly something is amiss. With the OSS API, you pass a number to the = = IOCTL, and it uses 2^n for the buffer size, so it isn't possible to even= = request a buffer size of 44, let alone recieve one that size. I tried using strace to figure out what's going on, but all I got was th= is: open("/dev/dsp", O_WRONLY) =3D 3 ioctl(3, SNDCTL_DSP_RESET, 0) =3D 0 ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, 0x810cadc) =3D 0 ioctl(3, SNDCTL_DSP_STEREO, 0x810cad8) =3D 0 ioctl(3, SNDCTL_DSP_SPEED or SOUND_PCM_READ_RATE, 0x810cae0) =3D 0 ioctl(3, SNDCTL_DSP_SETFMT or SOUND_PCM_READ_BITS, 0xbffd2040) =3D 0 ioctl(3, SNDCTL_DSP_SETFRAGMENT, 0x810cad4) =3D 0 It'd be nice to know what values are at those addresses, so that I could= = see what buffer size was requested, and what it actually got, but I gues= s = strace isn't going to tell me. Anyway, after tracking down the thread that actually writes the audio, I= = found that when I specify a sample size of 44, it writes data to the sou= nd = device in blocks of 176 bytes (2 channels * 2 bytes * 44 samples). So a= t = the very least, it *thinks* it's using a sample size of 44 bytes. So I had a look at the source code, where I found this: snd_fragment=3D0x00080009;//fragment size (?) It seems it uses the same buffer settings for OSS regardless of what = buffer size it is using itself. The above code means that it is using 8= = periods of 512 bytes each, or 128 samples each, for a total latency of 2= 3 = ms assuming I know how to calculate that correctly. That's actually qui= te = a latency I suppose, and it explains why a latency of 0.0 ms didn't soun= d = so impressive, but then I suppose, I'll recompile it and see what happen= s. I changed it to snd_fragment=3D0x00020008, to specify two periods of 256= = bytes, or 64 samples each, and I also added two lines of code to print o= ut = the requested sizes and what the OSS API agrees to use. (The API just = takes that value as a suggestion and returns what it actually decides to= = use.) fprintf(stderr, "Requested fragment size: 0x%08x\n", snd_fragment);= ioctl(snd_handle,SNDCTL_DSP_SETFRAGMENT,&snd_fragment); fprintf(stderr, "Recieved fragment size: 0x%08x\n", snd_fragment); Then I recompiled it and gave it a try: pj@sucks:~/zynaddsubfx$ zynaddsubfx -A -b 64 -l default.xmz ZynAddSubFX - Copyright (c) 2002-2005 Nasca Octavian Paul Compiled: Aug 25 2007 01:01:39 This program is free software (GNU GPL v.2) and it comes with ABSOLUTELY NO WARRANTY. Sound Buffer Size =3D 64 samples Internal latency =3D 1.5 ms ADsynth Oscil.Size =3D 1024 samples Requested fragment size: 0x00020008 Recieved fragment size: 0x00020008 Master file loaded. This caused a few xruns, but no worse than Jack has ever done, and = besides, it isn't even running under realtime priority, so what does one= = expect? ...but, to fix those xruns, just do this: pj@sucks:~$ ps -A | grep zynaddsubfx 5034 pts/0 00:00:02 zynaddsubfx pj@sucks:~$ sudo schedtool -R -p 90 5036 The important thing to note there is that the PID I gave realtime priori= ty = to was the PID of zynaddsubfx plus two. ZynAddSubFX creates four = processes (for a total of five) and it's the PID+2 process which actuall= y = outputs the audio. Doing it this way means that using the GUI won't fud= ge = up the output. So, I guess that's a 3 ms latency, with no xruns, at least with the kind= = of stuff I do. I tried 0.75 ms for a while, but then I decided to see = what happens when I choose a more complex insturment in ZynAddSubFX, set= = the key limit to 20, and mash down on the keyboard. Once I rebooted my = = computer, I decided that a sample period of 64 samples would be just fin= e. pj@sucks:~$ while sleep 1; do cat /proc/interrupts | grep EMU10K1 ; done= 5: 10297374 XT-PIC-XT EMU10K1 5: 10298082 XT-PIC-XT EMU10K1 5: 10298789 XT-PIC-XT EMU10K1 5: 10299502 XT-PIC-XT EMU10K1 5: 10300202 XT-PIC-XT EMU10K1 5: 10300907 XT-PIC-XT EMU10K1 5: 10301612 XT-PIC-XT EMU10K1 5: 10302316 XT-PIC-XT EMU10K1 5: 10303024 XT-PIC-XT EMU10K1 5: 10303730 XT-PIC-XT EMU10K1 5: 10304445 XT-PIC-XT EMU10K1 That looks like about 707.1 interrupts per second, which is about what I= = would expect for a period size of 64 samples, when 44100 / 64 =3D 689 an= d my = one second sleeps seem to always last a little longer than a second for = = some reason. So yes, ZynAddSubFX does 3 ms perfectly on the same system= = where Jack attempting 23 ms is just "borderline usable." I think Jack = might be a little broken. |
From: D. M. M. <mic...@ro...> - 2007-08-25 15:32:19
|
On Saturday 25 August 2007, Richard Cooper wrote: > Using 512 seems to cause a few each minute, and is what I would call > "borderline useable." > where Jack attempting 23 ms is just "borderline usable." I think Jack > might be a little broken. On the other hand, maybe your expectations are too high, or mine too low? I always leave JACK at 1024, with a calculated latency of 42.7 msec. I know I should be able to do better with my hardware (higher end CPU/mobo/soundcard) but I just don't care. I'm too stupid to understand why this is unacceptable. I just base acceptability on whether or not my infrequent creative inspiration drowns in a sea of xruns, and it usually doesn't with this setting. Though it's all so unpredictable. I think uptime is a factor too. More uptime means JACK is less likely to function properly. Mostly, though, I just play via my trusty Sound Canvas and run Rosegarden with no audio features at all. The last 10 times I used Rosegarden's audio features, I was just testing something. -- D. Michael McIntyre |
From: Richard C. <spa...@ec...> - 2007-08-26 21:41:22
|
On Sat, 25 Aug 2007 11:32:08 -0400, D. Michael McIntyre <mic...@ro...> wrote: > On the other hand, maybe your expectations are too high, or mine too low? > I always leave JACK at 1024, with a calculated latency of 42.7 msec. That's too much for me. It's a 48th note at 120 bpm. ...but then it kind of seems I'm pickier about timing than most people are, judging from the fact that I seem to always be adjusting the timing of things to the limit of what Rosegarden allows. I put Rosegarden's matrix editor in 48th or 64th note mode all the time in order to adjust the end point of notes. When I move segments around in the composition view, I zoom all the way in so that I can move them with finer resolution, and even then I adjust them one pixel at a time. I also wish that the delay option in the segment parameters box were just a number box so that I could type any milisecond value into it as the preset values sometimes don't seem sufficient, and I wish it would accept negative numbers as well since I usually wish to advance things rather than delay them. Anyway, regardless of all of that, in the past when I've had problems with Jack and realtime audio, I've had people tell me that they have Jack working with a period size of 8, which leads me to think that the 128 I aim for, which is about the point at which the latency ceases to be a problem for me, isn't too much to expect. A latency of 43 ms is what I would expect a system to be capable of without a special kernel and other modifications. At that rate it has 23 million clock cycles to put towards the task of assembling 1024 samples of audio data. If you can't service an interrupt and assemble 1024 samples of audio data in 23 million clock cycles, you've got a problem. Even so, Jack at 1024 works as well as my "not just-in-time" audio idea would when sequencing stuff, and so it isn't really a problem when sequencing stuff. It's just that I mostly like to use ZynAddSubFX just to play around live rather than for sequencing stuff, but that doesn't work well when there is a noticable latency between pressing a note and hearing it. It's too disturbing. > Mostly, though, I just play via my trusty Sound Canvas and run > Rosegarden with no audio features at all. The last 10 times Iused > Rosegarden's audio features, I was just testing something. I use the audio features to put someone else's music in one track so that I can recreate it in the other tracks. So far I've only done this for two whole songs and bits and pieces of some others, but each time I feel like I learn something about music by doing so. For example, I never would have thought it possible to create a great song by using just one drum pattern with the same fill-in every 4th measure throughout the entire song, but it seems it can be done. I listened to that song hundreds of times and never noticed the drum track was so repetative until I recreated it. That song also left me rather amazed that, as much as I hate the sounds of my Concertmate-990, it can still sound not so bad when playing the right music. At the same time, I suppose it's a bit upsetting that even with what I consider to be the best songwriting, it doesn't sound any better than it does. It's not like I put any great instrumental demands on it. There's no guitar in the song or any other instrument that MIDI doesn't do well. It was probably a MIDI itself before it was recorded to a CD. I can't think of any song I could have tried to make it play that would have turned out better, which makes it seem kind of impossible that it could create any music that I'd really like. I've been thinking that maybe I should get one of these: http://www.synthmania.com/micron.htm I just don't know if I want to spend $400 on a musical instrument. It's not like I'm a talented musician or anything, but it would elimiate what I hate most about my current keyboard, which is that it is soundfont-based. I hate it when I'm playing something and then I hit a note a little higher or lower than the one's I've been using only to find that that note happens to sound entirely different from the others due to the fact that it's generated from a different sample than the others. It does this even with instruments like the "Saw Lead" (#81/#82) which, being a synth instrument, you'd think would be just one sample throughout the entire range, but no, there are several. http://www.ecstaticlyrics.com/temporary/soundfonts.mp3 In that MP3 are a bunch of six note sets, the first three from one sample, the next three from a different sample for the same instrument. The last piano one is perhaps the most noticable, and the third one of the saw lead is perhaps the most obscene, and it makes no sense as I would've thought that for the saw wave they'd just use one sample for the entire note range. I hate soundfonts. |
From: D. M. M. <mic...@ro...> - 2007-08-27 22:04:27
|
On Sunday 26 August 2007, Richard Cooper wrote: > aim for, which is about the point at which the latency ceases to be a > problem for me, isn't too much to expect. If you're anywhere near getting performance like that, you're already light years ahead of me. > A latency of 43 ms is what I would expect a system to be capable of > without a special kernel and other modifications. In practice it should be, but in reality, that hasn't proven to be the case on any computer I've actually used. > sequencing stuff. It's just that I mostly like to use ZynAddSubFX just to > play around live rather than for sequencing stuff, but that doesn't work > well when there is a noticable latency between pressing a note and hearing > it. It's too disturbing. There's already latency in MIDI too. I'm not sure what the latency actually is, but I'm pretty sure it's more than enough to annoy you. > I just don't know if I want to spend $400 on a musical instrument. You should shop for flutes or trumpets! > It's > not like I'm a talented musician or anything, but it would elimiate what I > hate most about my current keyboard, which is that it is soundfont-based. I bought my Sound Canvas because I couldn't get the gigantic MIDI faking TSR for the Gravis UltraSound to work with most of my old DOS games, and few people ever supported that card. I bought a Logitech Soundman Wave because it had a real hardware MIDI interface inside, inasmuch as I could pick the plain MPU-401 driver from any game, and get the card to make noise, but it sounded seriously crappy. So one day I got a wild hair up my ass and I dropped $585 for this Sound Canvas. OUCH! I'm glad it still works 10 years later, although you would hate it. It has the split note problem bigtime, and probably only has something like 8 MB of sample ROM or something. Maybe not even that much. It's amazing how good it still sounds though. -- D. Michael McIntyre |
From: D. M. M. <mic...@ro...> - 2007-08-27 22:17:09
|
On Monday 27 August 2007, D. Michael McIntyre wrote: > I'm glad it still works 10 years later, although you would hate it. It has Wow. It has worked "10 years later" for two years now. It's really 12 years later. I'm getting old. -- D. Michael McIntyre |
From: Richard C. <spa...@ec...> - 2007-08-28 00:50:07
|
On Mon, 27 Aug 2007 18:04:12 -0400, D. Michael McIntyre = <mic...@ro...> wrote: > There's already latency in MIDI too. I'm not sure what the latency = > actually is, but I'm pretty sure it's more than enough to annoy you. MIDI is 31.25 kbits/sec, or something like that, and a note-on or note-o= ff = event is three bytes, which makes the latency about 1 ms, for just the = serial part, but I would hope everything else is faster than that. To test my perception, I created this awesome little Perl script, whose = = state of functionality depends on wether or not you have the same device= = name for your MIDI port. You can check with "hexdump -C < /dev/dmmidi" = on = whatever you suspect might be the device name of your MIDI port, and the= n = after you play a few notes on your keyboard (just one isn't enough) you = = should seem some numbers appear. If so, you've found the correct device= = name. Here's the script: #!/usr/bin/perl use Time::HiRes qw( gettimeofday ); sub militime { ($seconds, $microseconds) =3D gettimeofday; return $seconds + $microseconds / 1000000; }; open MIDI, "+</dev/dmmidi"; select MIDI; $| =3D 1; select STDOUT; $next =3D int(militime() + 1.25); $wait =3D $next - militime(); select undef, undef, undef, $wait; while ('latencies are everywhere') { print MIDI "\x99\x25\x64\x99\x25\x00"; $next +=3D 0.500; SELECT: vec($vector, fileno(MIDI), 1) =3D 1; $wait =3D $next - militime(); next unless select $vector, undef, undef, $wait; $time =3D militime(); sysread MIDI, $data, 4096, length($data); for ($i =3D 0; $i < length($data) - 2; $i++) { next unless substr($data, $i, 1) eq "\x90"; next unless substr($data, $i + 2, 1) ne "\x00"; if (abs($next - $time) <=3D 0.250) { $latency =3D $next - $time; } else { $latency =3D $next - $time - 0.500; }; $msecs =3D int(1000 * $latency + 0.5); print "Latency: $msecs miliseconds\n"; }; $data =3D substr($data, -2) if length($data) > 2; goto SELECT; }; close MIDI; Then you just listen to the 120 BPM drum sound it makes, and play a note= = at the same time as the drum sound as best you can, and it tells you how= = far off you are, like this: Latency: -4 miliseconds Latency: -4 miliseconds Latency: -26 miliseconds Latency: 5 miliseconds Latency: 4 miliseconds Latency: 17 miliseconds Latency: 25 miliseconds Latency: 24 miliseconds Latency: 31 miliseconds Latency: 26 miliseconds Latency: 23 miliseconds Latency: 8 miliseconds I'm just about always off in the positive direction, but I don't think = it's a bias of the script because if I play the same percussion sound it= 's = playing, it sounds distinctively different when two are played at the sa= me = time, and when that happens, the script always says something very close= = to zero, and so it appears to be accurate. So far the best I've been able to pull off is to get "-1" four times in = a = row, but usually it looks about like the above, in that I'm usually 20 t= o = 30 miliseconds late for some reason. However, even with that latency in synchronization, I still have some = sense of how well I'm doing even without looking at what the computer = says. When I hit a note 50 ms too late, I know it before I read it off = = the screen, so it isn't much surprise that a 43 ms latency in Jack = eventually catches my attention. It's more difficult to notice since = everything is delayed by 43 ms and so there's nothing to compare it to, = = but I eventually notice it anyway when the correct circumstances occur. I think what happens is that I'm playing along, and as I'm playing I'm = naturally trying to keep tempo with myself so that the music doesn't spe= ed = up or slow down, and I'm constantly creating these 25 ms errors all over= = the place, but in the process of trying to improve my performance by = trying to learn not to create those 25 ms errors, my brain runs into a = bump in that it doesn't understand where this constant 43 ms latency is = = coming from. It understands the latencies from my fingers and the = latencies of the audio portions of my brain, but the latency of Jack isn= 't = something that's been there since the day I was born and so it doesn't = know what to make of it. So it tries to synchronize with what it is = hearing, but it can't, because every time it tries to adjust my timing, = = what it's trying to synchronize to is misadjusted at the time, and so it= = never comes out correctly. |
From: Flemming B. <fl...@bj...> - 2007-08-29 20:04:45
|
Well, I have tried your script. But, it won't work. Please, could you give me a more concise desription of what I should do. I have: started jack, rosegarden and vkeybd. Then I ran the script and hexdump -C < /dev/dmmidi (the device exists). I hit vkeybd and produces midi-sound: Nothing happens. That's a pity, because now I have become curious about whether my pc runs significantly faster than yours. Flemming On Mon, 27 Aug 2007 20:49:57 -0400 "Richard Cooper" <spa...@ec...> wrote: > On Mon, 27 Aug 2007 18:04:12 -0400, D. Michael McIntyre > <mic...@ro...> wrote: > > > There's already latency in MIDI too. I'm not sure what the latency > > actually is, but I'm pretty sure it's more than enough to annoy you. > > MIDI is 31.25 kbits/sec, or something like that, and a note-on or note-off > event is three bytes, which makes the latency about 1 ms, for just the > serial part, but I would hope everything else is faster than that. > > To test my perception, I created this awesome little Perl script, whose > state of functionality depends on wether or not you have the same device > name for your MIDI port. You can check with "hexdump -C < /dev/dmmidi" on > whatever you suspect might be the device name of your MIDI port, and then > after you play a few notes on your keyboard (just one isn't enough) you > should seem some numbers appear. If so, you've found the correct device > name. > > Here's the script: > > #!/usr/bin/perl > use Time::HiRes qw( gettimeofday ); > > sub militime { > ($seconds, $microseconds) = gettimeofday; > return $seconds + $microseconds / 1000000; > }; > > open MIDI, "+</dev/dmmidi"; select MIDI; $| = 1; select STDOUT; > $next = int(militime() + 1.25); > $wait = $next - militime(); > select undef, undef, undef, $wait; > while ('latencies are everywhere') { > print MIDI "\x99\x25\x64\x99\x25\x00"; > $next += 0.500; SELECT: > vec($vector, fileno(MIDI), 1) = 1; > $wait = $next - militime(); > next unless select $vector, undef, undef, $wait; > $time = militime(); sysread MIDI, $data, 4096, length($data); > for ($i = 0; $i < length($data) - 2; $i++) { > next unless substr($data, $i, 1) eq "\x90"; > next unless substr($data, $i + 2, 1) ne "\x00"; > if (abs($next - $time) <= 0.250) { > $latency = $next - $time; > } else { > $latency = $next - $time - 0.500; > }; $msecs = int(1000 * $latency + 0.5); > print "Latency: $msecs miliseconds\n"; > }; $data = substr($data, -2) if length($data) > 2; > goto SELECT; > }; > close MIDI; > > Then you just listen to the 120 BPM drum sound it makes, and play a note > at the same time as the drum sound as best you can, and it tells you how > far off you are, like this: > > Latency: -4 miliseconds > Latency: -4 miliseconds > Latency: -26 miliseconds > Latency: 5 miliseconds > Latency: 4 miliseconds > Latency: 17 miliseconds > Latency: 25 miliseconds > Latency: 24 miliseconds > Latency: 31 miliseconds > Latency: 26 miliseconds > Latency: 23 miliseconds > Latency: 8 miliseconds > > I'm just about always off in the positive direction, but I don't think > it's a bias of the script because if I play the same percussion sound it's > playing, it sounds distinctively different when two are played at the same > time, and when that happens, the script always says something very close > to zero, and so it appears to be accurate. > > So far the best I've been able to pull off is to get "-1" four times in a > row, but usually it looks about like the above, in that I'm usually 20 to > 30 miliseconds late for some reason. > > However, even with that latency in synchronization, I still have some > sense of how well I'm doing even without looking at what the computer > says. When I hit a note 50 ms too late, I know it before I read it off > the screen, so it isn't much surprise that a 43 ms latency in Jack > eventually catches my attention. It's more difficult to notice since > everything is delayed by 43 ms and so there's nothing to compare it to, > but I eventually notice it anyway when the correct circumstances occur. > > I think what happens is that I'm playing along, and as I'm playing I'm > naturally trying to keep tempo with myself so that the music doesn't speed > up or slow down, and I'm constantly creating these 25 ms errors all over > the place, but in the process of trying to improve my performance by > trying to learn not to create those 25 ms errors, my brain runs into a > bump in that it doesn't understand where this constant 43 ms latency is > coming from. It understands the latencies from my fingers and the > latencies of the audio portions of my brain, but the latency of Jack isn't > something that's been there since the day I was born and so it doesn't > know what to make of it. So it tries to synchronize with what it is > hearing, but it can't, because every time it tries to adjust my timing, > what it's trying to synchronize to is misadjusted at the time, and so it > never comes out correctly. > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Rosegarden-user mailing list > Ros...@li... - use the link below to unsubscribe > https://lists.sourceforge.net/lists/listinfo/rosegarden-user |
From: Abrolag <ab...@us...> - 2007-08-28 14:09:58
|
On Mon, 27 Aug 2007 20:49:57 -0400 "Richard Cooper" <spa...@ec...> wrote: > I think what happens is that I'm playing along, and as I'm playing I'm > naturally trying to keep tempo with myself so that the music doesn't speed > up or slow down, and I'm constantly creating these 25 ms errors all over > the place, but in the process of trying to improve my performance by > trying to learn not to create those 25 ms errors, my brain runs into a > bump in that it doesn't understand where this constant 43 ms latency is > coming from. It understands the latencies from my fingers and the > latencies of the audio portions of my brain, but the latency of Jack isn't > something that's been there since the day I was born and so it doesn't > know what to make of it. So it tries to synchronize with what it is > hearing, but it can't, because every time it tries to adjust my timing, > what it's trying to synchronize to is misadjusted at the time, and so it > never comes out correctly. Interesting you come up wit 25mS. I seem to remember (dimly) reading that auditory response time was approximately 20mS -- Will J Godfrey http://www.musically.me.uk |
From: Richard C. <spa...@ec...> - 2007-08-28 16:11:42
|
On Tue, 28 Aug 2007 10:09:51 -0400, Abrolag = <ab...@us...> wrote: > Interesting you come up wit 25mS. I seem to remember (dimly) reading > that auditory response time was approximately 20mS Response time is something else, and much slower. Here's a script I mad= e = to test response time. It plays a drum after a random delay, and you = respond by playing any note, and after ten times it displays your averag= e. #!/usr/bin/perl use Time::HiRes qw( gettimeofday ); sub militime { ($seconds, $microseconds) =3D gettimeofday; return $seconds + $microseconds / 1000000; }; open MIDI, "+</dev/dmmidi"; select MIDI; $| =3D 1; select STDOUT; for ($i =3D 0; $i < 10; $i++) { while ('...') { vec($vector, fileno(MIDI), 1) =3D 1; if (select $vector, undef, undef, 2) { sysread MIDI, $data, 4096; } else { last; }; }; $wait =3D rand(7); select undef, undef, undef, $wait; print MIDI "\x99\x28\x64\x99\x28\x00"; $start =3D militime(); sysread MIDI, $data, 4096; $stop =3D militime(); $latency =3D int(1000 * ($stop - $start) + 0.5); print "Your reaction time: $latency miliseconds\n"; $total +=3D $latency; }; $total =3D int($total / 10 + 0.5); print "Average reaction time: $total miliseconds\n"; close MIDI; Using that script, I get results like this: Your reaction time: 233 miliseconds Your reaction time: 219 miliseconds Your reaction time: 164 miliseconds Your reaction time: 190 miliseconds Your reaction time: 210 miliseconds Your reaction time: 254 miliseconds Your reaction time: 214 miliseconds Your reaction time: 228 miliseconds Your reaction time: 212 miliseconds Your reaction time: 206 miliseconds Average reaction time: 213 miliseconds The best I've managed to do so far is 135 ms. As for my other script, I've become much better at timing with a small = amount of practice, and I've learned not to be 20 ms late every time. I= = also changed the script to create a graph, which looks like this: -120 -110 -100 -90 -80 -70 -60 -50 -40 -30 =3D -20 =3D=3D=3D=3D=3D=3D=3D=3D -10 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 0 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 10 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 30 =3D=3D=3D=3D=3D 40 50 60 70 80 90 100 110 120 The '0' field contains values from -5 to +5, and the '-10' field contain= s = values from -5 to -15, etc. ...or something like that, since obviously = -5 = isn't counted in both of them, but I hate Perl's broken int() function s= o = I'm not going to think about it. Anyway, synchronizing to a sound is a lot easier than reacting to a soun= d, = as most of those are within 25 ms, but my reaction time seems to be ten = = times worse. Here's the script that makes the graph: #!/usr/bin/perl use Time::HiRes qw( gettimeofday ); sub militime { ($seconds, $microseconds) =3D gettimeofday; return $seconds + $microseconds / 1000000; }; open MIDI, "+</dev/dmmidi"; select MIDI; $| =3D 1; select STDOUT; $next =3D int(militime() + 1.25); $wait =3D $next - militime(); select undef, undef, undef, $wait; while ('latencies are everywhere') { print MIDI "\x99\x25\x64\x99\x25\x00"; $next +=3D 0.250; SELECT: vec($vector, fileno(MIDI), 1) =3D 1; $wait =3D $next - militime(); next unless select $vector, undef, undef, $wait; $time =3D militime(); sysread MIDI, $data, 4096, length($data); for ($i =3D 0; $i < length($data) - 2; $i++) { next unless substr($data, $i, 1) eq "\x90"; next unless substr($data, $i + 2, 1) ne "\x00"; if (abs($next - $time) <=3D 0.125) { $latency =3D $next - $time; } else { $latency =3D $next - $time - 0.250; }; $msecs =3D int(1000 * $latency + 0.5 * ($latency <=3D> 0)); $bucket =3D int(100 * $latency + 0.5 * ($latency <=3D> 0)); $bucket =3D +12 if $bucket > +12; $bucket =3D -12 if $bucket < -12; exit if ++$buckets[$bucket+12] > 60; print "\e[d\e[2J"; for ($i =3D 0; $i <=3D 24; $i++) { $v =3D 10 * ($i - 12); $v =3D substr(' ' . $v, -4); print "$v " . '=3D' x $buckets[$i] . "\n"; }; if (abs($msecs) <=3D 16) { print "\e[1;33mLatency: $msecs miliseconds\e[0m\n"; } else { print "Latency: $msecs miliseconds\n"; }; }; $data =3D substr($data, -2) if length($data) > 2; goto SELECT; }; close MIDI; I've noticed my scripts don't work while other MIDI applications are = running. I suppose my scripts also won't work if anyone's keyboard does= = "running status." |
From: Marcos G. <mar...@gm...> - 2007-09-18 20:23:46
|
| On Saturday 25 August 2007, Richard Cooper wrote: | > Using 512 seems to cause a few each minute, and is what I would call | > "borderline useable." | > | > where Jack attempting 23 ms is just "borderline usable." I think Jack | > might be a little broken. | | On the other hand, maybe your expectations are too high, or mine too low= ?=20 | I always leave JACK at 1024, with a calculated latency of 42.7 msec. I | know I should be able to do better with my hardware (higher end | CPU/mobo/soundcard) but I just don't care. I'm too stupid to understand | why this is | unacceptable. I just base acceptability on whether or not my infrequent | creative inspiration drowns in a sea of xruns, and it usually doesn't wi= th | this setting. | | Though it's all so unpredictable. I think uptime is a factor too. More | uptime means JACK is less likely to function properly. | | Mostly, though, I just play via my trusty Sound Canvas and run Rosegarden | with no audio features at all. The last 10 times I used Rosegarden's | audio features, I was just testing something. Hi ;) What version of jackd are you using? apt-cache policy jackd jackd: Installed: 0.103.0-6 Candidate: 0.103.0-6 Version table: *** 0.103.0-6 0 500 ftp://musix.ourproject.org ./ Packages 100 /var/lib/dpkg/status 0.101.1-2 0 500 ftp://musix.ourproject.org ./ Packages 0.101.1-2 0 500 ftp://ftp.fr.debian.org etch/main Packages Here it works fine. Also, linux-image-2.6.22.1-rt4 works fine too. apt-cache policy linux-image-2.6.22.1-rt4 linux-image-2.6.22.1-rt4: Installed: 2.6.22.1-rt4-10.00.Custom Candidate: 2.6.22.1-rt4-10.00.Custom Version table: *** 2.6.22.1-rt4-10.00.Custom 0 500 ftp://musix.ourproject.org ./ Packages 100 /var/lib/dpkg/status Also Ardour apt-cache policy ardour2 ardour2: Installed: 2.0.4-1 Candidate: 2.0.5-1 Version table: 2.0.5-1 0 500 ftp://musix.ourproject.org ./ Packages *** 2.0.4-1 0 100 /var/lib/dpkg/status =2D-=20 =A0 =A0 =A0`&'=20 =A0 =A0 =A0 # =A0 =A0Marcos Guglielmetti, co-director de =A0 =A0 =A0 =A0 = =A0 =A0 =A0=20 =A0 =A0 =A0 # =A0 Musix GNU+Linux, 100% Software Libre para artistas =A0 = =A0 =A0 =A0 =A0 =A0_#_ =A0 =A0 =A0 http://www.musix.org.ar =A0 =A0 =A0 =A0 =A0=20 =A0 =A0 =A0(#) =A0 =A0=20 =A0 =A0 / O \ =A0 =A0+ archivos: ftp://musix.ourproject.org/pub/musix =A0 =A0( =3D=3D=3D ) =A0 Ecolog=EDa: http://autosus.wordpress.com =A0 =A0 =A0 =A0 `---' =A0 =A0Personal: http://marcospcmusica.wordpress.com "Somos m=E1s libres, porque somos m=E1s plenos."=20 Ernesto Guevara http://es.wikiquote.org/wiki/Libertad |
From: D. M. M. <mic...@ro...> - 2007-09-19 01:50:57
|
On Tuesday 18 September 2007, Marcos Guglielmetti wrote: > | Though it's all so unpredictable. I think uptime is a factor too. More > | uptime means JACK is less likely to function properly. > | > | Mostly, though, I just play via my trusty Sound Canvas and run > | Rosegarden with no audio features at all. The last 10 times I used > | Rosegarden's audio features, I was just testing something. > > Hi ;) > > What version of jackd are you using? jackd: Installed: 0.102.20-1 Anyway, it's worth noting for the record that after the second or third time I had to reboot after my ATI video drivers froze, my soundcards rearranged themselves. hw:0 is now my emu10k1, and hw:1 is my ice1712. I reconfigured QJackCtl to accommodate this change, and dialed it to 5.33 ms latency, instead of my usual standby of 42.7. I haven't had an xrun in days. Interesting, isn't it? I'd better never reboot again, because this will probably never happen again. This seems to be a random fluke best case scenario. -- D. Michael McIntyre |
From: Marcos G. <mar...@gm...> - 2007-09-19 03:07:18
|
El Mi=C3=A9rcoles, 19 de Septiembre de 2007 03:50, D. Michael McIntyre escr= ibi=C3=B3: | On Tuesday 18 September 2007, Marcos Guglielmetti wrote: | > | Though it's all so unpredictable. I think uptime is a factor too.= =20 | > | More uptime means JACK is less likely to function properly. | > | | > | Mostly, though, I just play via my trusty Sound Canvas and run | > | Rosegarden with no audio features at all. The last 10 times I used | > | Rosegarden's audio features, I was just testing something. | > | > Hi ;) | > | > What version of jackd are you using? | | jackd: | Installed: 0.102.20-1 | | Anyway, it's worth noting for the record that after the second or third | time I had to reboot after my ATI video drivers froze,=20 non free drivers? | my soundcards=20 | rearranged themselves. hw:0 is now my emu10k1, and hw:1 is my ice1712. = I | reconfigured QJackCtl to accommodate this change,=20 Well, about the soundcard's order, see: http://h.ordia.com.ar/blog/index.php?entry=3Dentry061127-202822 "Configurando el orden de detecci=C3=B3n de las placas de sonido en linux" Sorry, spanish for now (a friend's blog) "Desde que tengo 2 plaquetas de sonido me pasa que mi Kubuntu me reconoce a= =20 veces primero una placa y otras veces la otra como primer dispositivo=20 (/dev/dsp) y eso me traia problemas con la configuraci=C3=B3n general del s= istema,=20 programas, el archivo .asoundrc de alsa, etc. Como no reinicio mucho la=20 m=C3=A1quina no me represantaba un problema mayor, porque cada vez que lo h= acia me=20 aseguraba de que queden en el orden deseado (reiniciando hasta que queden=20 como yo quer=C3=ADa :-( ). Encontr=C3=A9 que por medio de udev se pueden establecer reglas para forzar= el=20 orden de detecci=C3=B3n/asignaci=C3=B3n: En el archivo =E2=80=9C/etc/udev/rules.d/20-names.rules=E2=80=9D puse estas= dos reglas: # sound card with PCI bus id 00:0d.0 to be called dsp (SB Live)=20 BUS=3D=3D"pci", ID=3D=3D"00:0d.0", NAME=3D"dsp" # sound card with PCI bus id 00:0c.0 to be called dsp1 (SoundFusion)=20 BUS=3D=3D"pci", ID=3D=3D"00:0c.0", NAME=3D"dsp1" el id del bus lo averigu=C3=A9 con el comando lspci, que me arroj=C3=B3 alg= o como: =E2=80=A6 0000:00:0c.0 Multimedia audio controller: Cirrus Logic CS 4614/22/24=20 [CrystalClear SoundFusion Audio Accelerator] (rev 01) 0000:00:0d.0 Multimedia audio controller: Creative Labs SB Audigy LS" More info: http://audiores.uint8.com.ar/blog/?p=3D109 | and dialed it to 5.33 ms=20 | latency, instead of my usual standby of 42.7. I haven't had an xrun in | days. | | Interesting, isn't it? =20 Yes: 5.33 is interesting, always | I'd better never reboot again, because this will probably never happen | again. This seems to be a random fluke best case scenario. hehe =2D-=20 =C2=A0 =C2=A0 =C2=A0`&'=20 =C2=A0 =C2=A0 =C2=A0 # =C2=A0 =C2=A0Marcos Guglielmetti, co-director de =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0 =C2=A0 # =C2=A0 Musix GNU+Linux, 100% Software Libre para art= istas =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_#_ =C2=A0 =C2=A0 =C2=A0 http://www.musix.org.ar =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0 =C2=A0(#) =C2=A0 =C2=A0=20 =C2=A0 =C2=A0 / O \ =C2=A0 =C2=A0+ archivos: ftp://musix.ourproject.org/pub= /musix =C2=A0 =C2=A0( =3D=3D=3D ) =C2=A0 Ecolog=C3=ADa: http://autosus.wordpress.c= om =C2=A0 =C2=A0 =C2=A0 =C2=A0 `---' =C2=A0 =C2=A0Personal: http://marcospcmusica.wordpress.= com "=C2=A1Ya c=C3=A1llate, c=C3=A1llate, c=C3=A1llate que me desespeeeeras!" http://es.wikiquote.org/wiki/El_Chavo_del_Ocho |
From: D. M. M. <mic...@ro...> - 2007-09-19 09:55:59
|
On Tuesday 18 September 2007, Marcos Guglielmetti wrote: > | Anyway, it's worth noting for the record that after the second or third > | time I had to reboot after my ATI video drivers froze, > > non free drivers? Unfortunately, yes. My kids love to play with Google Earth. > Well, about the soundcard's order, see: I'll have to try that. > Yes: 5.33 is interesting, always I got 11 xruns during my big nightly cron jobs. That's probably not unreasonable. -- D. Michael McIntyre |