Re: [LAD] [64studio-users] MIDI jitter
Ichthyostega wrote: Ralf Mardorf schrieb: Another stupid question induced by an argument regarding to MIDI jitter by Daniel James. [snip] I'm sceptical that the realtime kernel is the cause of your MIDI problems. If they got this right in the 80's, on computers which could not do anything near realtime audio processing, then I think it's more likely to be a question of MIDI application design. At that point we should call back, how that whole story with "realtime" started. At the begining was a design mismatch. Many things related to the Linux kernel started out with a kind of "I feel fine" pragmatism. Which, btw isn't to criticise as it is, because this also accounts for the freshness and sometime unconventional new approach to some problems. But with regards to timings, for all of the first decade of Linux development, there seemed to be a completely different mental model, which we could summarise as: permormance == throughput, and timings are only relevant, when you get a network timeout, or a sluggish response in your application's GUI. Thus, if we now consider to use a Linux kernel for making music, we must assess that the whole design isochronously assumed about 1000 times more headroom as there really is. Thus, as writing a new Kernel doesn't seem to be an option, this whole tedious undertaking of the "realtime patches" can be described as an attempt to fix this "problem" (which was never assumed to be a problem in the initial design) by hunting down one by one each individual instance where the existing kernel could possibly be reacting too slow. Thus, we should rather be surprised, how good these realtime kernels work. OTOH, is isn't a surprise the machines from the 80s meet these criteria; their OS software was written with an awareness for a much more limited processing capability right from start. Why do people (not only me) report jitter for external MIDI equipment, but I couldn't find any report for real-time audio jitter? Resp. what's about async and disconnecting clients by JACK? Audio and MIDI are two quite different beasts. Sound is processed in Blocks, where the individual unity (1 Sample) is much more fine grained and way below anything which can be discerned by a human ear. Moreover, Sound as such already exists and 'just' has to be piped through. To the contrary, MIDI consists of events, which immediately trigger a reaction, which could be that a piece of software and at the same time a piece of external hardware starts a processing cycle. You see, thats a completely different situation and thus it's obvious, why for these two media the same problem causes so different symptoms. OTOH on Windows audio clients don't disconnect, just MIDI jitter is an issue too. IIRC, this was a design decision for JACK. It never tries to conceal any timeout problem, rather it requires its clients to keep up with a very tight schedule and comply to very strict rules. I don't know the MIDI part of Jack well enough to judge, if it was designed with the same "you're required to comply" policy. And besides, when the MIDI interface is hooked up via USB, we again face a completely different situation. USB is a complicated protocol, which multiple versions and levels and is certainly not designed to get an individual event transfered reliably with less than 2ms jitter. There is even the possibility that the USB peers negotiate to use a lower transfer rate or protocol version transparently, when they determine the connection can't keep up with the higher speed. Cheers Hermann V. It's said that USB MIDI interfaces should be the better choice. But this explains a lot. Dunno how to read Fons JACK MIDI jitter test, but ... Subject:Re: [LAD] Again MIDI jitter - tested with Fons test applications Date: Sat, 27 Mar 2010 18:26:33 +0100 From: Ralf Mardorf To: f...@kokkinizita.net CC: linux-audio-dev@lists.linuxaudio.org References: <4badbd42.4030...@alice-dsl.net> <20100327164326.gd1...@zita2> Hi Fons :) f...@kokkinizita.net wrote: > On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf Mardorf wrote: > > >> Regular it shifted between 2395 and 2404, but with a few exceptions, >> one time 2302, three times 2304, two times 2305 and two time 2494. >> See attachment. >> What might cause this exceptions? Could it be access to the RAM by >> the graphics? Is there something bad because of the IRQs? >> >> Regular shift 2404 - 2395 = 9 frames of jitter, exceptional maximal >> shift 2494 - 2302 = 192 frames of jitter. >> >> I guess this does mean ... >> 5.3 ms / 512 frames = 0.010351562 ms/frame >> Maximal difference for regular jitter 0.093164062 ms. >> Maximal difference for exceptional jitter 1.9875 ms. >> ... am I wrong? >> > > Wrong once or twice, if twice in such a way that the two > errors cancel out. > > First note that the test prints the difference between > events. That means that e.g. if *one* note is 100 samples > late you could see 2400 2500 2300 2400. >
Re: [LAD] [64studio-users] MIDI jitter
On Saturday 19 June 2010, Ralf Mardorf wrote: This will go back only to LAD as I'm not subbed to the others, Ralf. >Ichthyostega wrote: >> Ralf Mardorf schrieb: >>> Another stupid question induced by an argument regarding to MIDI jitter >>> by Daniel James. >>> [snip] I'm sceptical that the realtime kernel is the cause of your MIDI problems. If they got this right in the 80's, on computers which could not do anything near realtime audio processing, then I think it's more likely to be a question of MIDI application design. >> >> At that point we should call back, how that whole story with "realtime" >> started. At the begining was a design mismatch. Many things related to >> the Linux kernel started out with a kind of "I feel fine" pragmatism. >> Which, btw isn't to criticise as it is, because this also accounts >> for the freshness and sometime unconventional new approach to some >> problems. But with regards to timings, for all of the first decade >> of Linux development, there seemed to be a completely different >> mental model, which we could summarise as: permormance == throughput, >> and timings are only relevant, when you get a network timeout, or >> a sluggish response in your application's GUI. >> >> Thus, if we now consider to use a Linux kernel for making music, we must >> assess that the whole design isochronously assumed about 1000 times more >> headroom as there really is. >> >> Thus, as writing a new Kernel doesn't seem to be an option, this whole >> tedious undertaking of the "realtime patches" can be described as an >> attempt to fix this "problem" (which was never assumed to be a problem >> in the initial design) by hunting down one by one each individual >> instance where the existing kernel could possibly be reacting too slow. >> >> Thus, we should rather be surprised, how good these realtime kernels >> work. OTOH, is isn't a surprise the machines from the 80s meet these >> criteria; their OS software was written with an awareness for a much >> more limited processing capability right from start. >> >>> Why do people (not only me) report jitter for external MIDI equipment, >>> but I couldn't find any report for real-time audio jitter? Resp. what's >>> about async and disconnecting clients by JACK? >> >> Audio and MIDI are two quite different beasts. >> Sound is processed in Blocks, where the individual unity (1 Sample) is >> much more fine grained and way below anything which can be discerned by >> a human ear. Moreover, Sound as such already exists and 'just' has to >> be piped through. To the contrary, MIDI consists of events, which >> immediately trigger a reaction, which could be that a piece of software >> and at the same time a piece of external hardware starts a processing >> cycle. You see, thats a completely different situation and thus it's >> obvious, why for these two media the same problem causes so different >> symptoms. >> >>> OTOH on Windows audio clients don't disconnect, >>> just MIDI jitter is an issue too. >> >> IIRC, this was a design decision for JACK. It never tries to conceal >> any timeout problem, rather it requires its clients to keep up with >> a very tight schedule and comply to very strict rules. >> >> I don't know the MIDI part of Jack well enough to judge, if it was >> designed with the same "you're required to comply" policy. And besides, >> when the MIDI interface is hooked up via USB, we again face a completely >> different situation. USB is a complicated protocol, which multiple >> versions and levels and is certainly not designed to get an individual >> event transfered reliably with less than 2ms jitter. >> There is even the possibility that the USB peers negotiate to use a >> lower transfer rate or protocol version transparently, when they >> determine the connection can't keep up with the higher speed. >> >> Cheers >> Hermann V. > >It's said that USB MIDI interfaces should be the better choice. But this >explains a lot. Dunno how to read Fons JACK MIDI jitter test, but ... On the face of it, and reading the USB specs, USB would seem to be a poor choice for midi unless it re-clocks everything.before sending it out the MIDI port. Usb has a 10 millisecond worst case lag in the specs. > >Subject: Re: [LAD] Again MIDI jitter - tested with Fons test applications >Date: Sat, 27 Mar 2010 18:26:33 +0100 >From: Ralf Mardorf >To:f...@kokkinizita.net >CC:linux-audio-dev@lists.linuxaudio.org >References:<4badbd42.4030...@alice-dsl.net> > <20100327164326.gd1...@zita2> > >> Hi Fons :) >> >> f...@kokkinizita.net wrote: >> > On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf Mardorf wrote: >> >> Regular it shifted between 2395 and 2404, but with a few exceptions, >> >> one time 2302, three times 2304, two times 2305 and two time 2494. >> >> See attachment. >> >> What might cause this exceptions? Could it be access to the RAM by >> >> the graphics? Is there something bad because of the IRQs? >> >> >> >> Regular shift 2404 -
Re: [LAD] [64studio-users] MIDI jitter
Hi Gene :) Gene Heskett wrote: On Saturday 19 June 2010, Ralf Mardorf wrote: This will go back only to LAD as I'm not subbed to the others, Ralf. Ichthyostega wrote: Ralf Mardorf schrieb: Another stupid question induced by an argument regarding to MIDI jitter by Daniel James. [snip] I'm sceptical that the realtime kernel is the cause of your MIDI problems. If they got this right in the 80's, on computers which could not do anything near realtime audio processing, then I think it's more likely to be a question of MIDI application design. At that point we should call back, how that whole story with "realtime" started. At the begining was a design mismatch. Many things related to the Linux kernel started out with a kind of "I feel fine" pragmatism. Which, btw isn't to criticise as it is, because this also accounts for the freshness and sometime unconventional new approach to some problems. But with regards to timings, for all of the first decade of Linux development, there seemed to be a completely different mental model, which we could summarise as: permormance == throughput, and timings are only relevant, when you get a network timeout, or a sluggish response in your application's GUI. Thus, if we now consider to use a Linux kernel for making music, we must assess that the whole design isochronously assumed about 1000 times more headroom as there really is. Thus, as writing a new Kernel doesn't seem to be an option, this whole tedious undertaking of the "realtime patches" can be described as an attempt to fix this "problem" (which was never assumed to be a problem in the initial design) by hunting down one by one each individual instance where the existing kernel could possibly be reacting too slow. Thus, we should rather be surprised, how good these realtime kernels work. OTOH, is isn't a surprise the machines from the 80s meet these criteria; their OS software was written with an awareness for a much more limited processing capability right from start. Why do people (not only me) report jitter for external MIDI equipment, but I couldn't find any report for real-time audio jitter? Resp. what's about async and disconnecting clients by JACK? Audio and MIDI are two quite different beasts. Sound is processed in Blocks, where the individual unity (1 Sample) is much more fine grained and way below anything which can be discerned by a human ear. Moreover, Sound as such already exists and 'just' has to be piped through. To the contrary, MIDI consists of events, which immediately trigger a reaction, which could be that a piece of software and at the same time a piece of external hardware starts a processing cycle. You see, thats a completely different situation and thus it's obvious, why for these two media the same problem causes so different symptoms. OTOH on Windows audio clients don't disconnect, just MIDI jitter is an issue too. IIRC, this was a design decision for JACK. It never tries to conceal any timeout problem, rather it requires its clients to keep up with a very tight schedule and comply to very strict rules. I don't know the MIDI part of Jack well enough to judge, if it was designed with the same "you're required to comply" policy. And besides, when the MIDI interface is hooked up via USB, we again face a completely different situation. USB is a complicated protocol, which multiple versions and levels and is certainly not designed to get an individual event transfered reliably with less than 2ms jitter. There is even the possibility that the USB peers negotiate to use a lower transfer rate or protocol version transparently, when they determine the connection can't keep up with the higher speed. Cheers Hermann V. It's said that USB MIDI interfaces should be the better choice. But this explains a lot. Dunno how to read Fons JACK MIDI jitter test, but ... On the face of it, and reading the USB specs, USB would seem to be a poor choice for midi unless it re-clocks everything.before sending it out the MIDI port. Usb has a 10 millisecond worst case lag in the specs. To bad that there isn't a MPU game port any more on modern boards and that e.g. my Terratec EWX 24/96 Envy24's MPU needs opto-couplers for the cable, but what ever circuit I build on a brad board, they failed. Time to mount my old mobo again and to test the game ports MPU with today Linux, resp. to get a service manual for my Terratec. Subject:Re: [LAD] Again MIDI jitter - tested with Fons test applications Date: Sat, 27 Mar 2010 18:26:33 +0100 From: Ralf Mardorf To: f...@kokkinizita.net CC: linux-audio-dev@lists.linuxaudio.org References: <4badbd42.4030...@alice-dsl.net> <20100327164326.gd1...@zita2> Hi Fons :) f...@kokkinizita.net wrote: On Sat, Mar 27, 2010 at 09:09:38AM +0100, Ralf Mardorf wrote: Regular it shifted between 2395 and 2404, but with a few exceptions, one time 23
Re: [LAD] [64studio-users] MIDI jitter
On Saturday 19 June 2010, Ralf Mardorf wrote: >Hi Gene :) [huge snip] >> Being an ardent purist can bite you. As another friend of mine would >> say, use what works. > >No Windows! If needed I'll write to your friend and get that Atari-VGA >interface, get a SMPTE interface again and an anlog audio recorder >again. I also would change the SCSI hard disk in the Lacom interface, >it's a 42 MB Seagate, without any free space and it sometimes fails on >startup. The main problem is, that I don't have the money jet and it's >not that easy to get the money. Another issue is, that I guess it's time >to use modern software, because it also comes with some advantages >compared to 80ies software made for the Atari and to the very old >hardware. E.g. what would happen if one day a chip in the Steinberg >dongle should break? It has been my experience that such dongles have a lifetime of about a year. Or less. Story time: Years ago, we setup a graphics system that involved using the A&B Roll Editing (or something like that name) amiga software to control 2 editing S-VHS vcr's, Panasonic 7750's. That came with a parport dongle, without which it would not work. And it was a $25,000 package. They, after lots of argument, and receiving the old dongle, would replace it when it failed. eventually that program was sold to RVS, Ring Video Systems, some fly by night down in FL. The dongle failed again (there was no printer attached to its output port ever) and they screwed around for 6 months, finally going to the original authors house to get the last dongle in existence after we threatened to sue. It lasted about 3 months. By then the hacking business was running full tilt in the amiga world, so when they said no more dongle, we said we're gonna hack it, sue us if you dare. We sent it off to one of the hackers, and had a working system back on-line in 3 days. RVS in turn had one of their programmers try to take it out, and 3 copies later over about 2 weeks, they failed. And we laughed at them on the phone when the last one they sent didn't work. To this day, I believe we only have one dongle protected system at the station & that was because they said there wasn't one, but there was. We simply do not consider for purchase, any system that uses a dongle for copy protection. And we are not exactly silent when we tell some vendor, sorry, you use a trouble prone technology so we will not even consider your product/equipment. When we are writing checks for $100k and up for the new digital stuff, we are justifiably being picky. If the vendor doesn't like it, the exit door is that way, come back when you can offer us something that Just Works(TM). Its been remarkably effective at separating out the rectums in the business. >Cheers! > >Ralf > -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Undetectable errors are infinite in variety, in contrast to detectable errors, which by definition are limited -- SNAFU Equations (JB's Scholastic Laws) n�3 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
Gene Heskett wrote: On Saturday 19 June 2010, Ralf Mardorf wrote: Hi Gene :) [huge snip] Being an ardent purist can bite you. As another friend of mine would say, use what works. No Windows! If needed I'll write to your friend and get that Atari-VGA interface, get a SMPTE interface again and an anlog audio recorder again. I also would change the SCSI hard disk in the Lacom interface, it's a 42 MB Seagate, without any free space and it sometimes fails on startup. The main problem is, that I don't have the money jet and it's not that easy to get the money. Another issue is, that I guess it's time to use modern software, because it also comes with some advantages compared to 80ies software made for the Atari and to the very old hardware. E.g. what would happen if one day a chip in the Steinberg dongle should break? It has been my experience that such dongles have a lifetime of about a year. Or less. Story time: Years ago, we setup a graphics system that involved using the A&B Roll Editing (or something like that name) amiga software to control 2 editing S-VHS vcr's, Panasonic 7750's. That came with a parport dongle, without which it would not work. And it was a $25,000 package. They, after lots of argument, and receiving the old dongle, would replace it when it failed. eventually that program was sold to RVS, Ring Video Systems, some fly by night down in FL. The dongle failed again (there was no printer attached to its output port ever) and they screwed around for 6 months, finally going to the original authors house to get the last dongle in existence after we threatened to sue. It lasted about 3 months. By then the hacking business was running full tilt in the amiga world, so when they said no more dongle, we said we're gonna hack it, sue us if you dare. We sent it off to one of the hackers, and had a working system back on-line in 3 days. RVS in turn had one of their programmers try to take it out, and 3 copies later over about 2 weeks, they failed. And we laughed at them on the phone when the last one they sent didn't work. To this day, I believe we only have one dongle protected system at the station & that was because they said there wasn't one, but there was. We simply do not consider for purchase, any system that uses a dongle for copy protection. And we are not exactly silent when we tell some vendor, sorry, you use a trouble prone technology so we will not even consider your product/equipment. When we are writing checks for $100k and up for the new digital stuff, we are justifiably being picky. If the vendor doesn't like it, the exit door is that way, come back when you can offer us something that Just Works(TM). Its been remarkably effective at separating out the rectums in the business. Cheers! Ralf The Steinberg dongle seems to be ok, since it's from the 80ies or beginning 90ies and was used for several years without getting broken. But exactly because it's that old I fear it could break one day. I 'guess' that I also could get cracked versions of Cubase for the Atari, but while the dongle version is 100% stable and the latest version ever made for the Atari, there aren't cracks for the latest version and the cracks I know were '99%' stable. For Windows there are dongle hacks available by torrent, they do work '99,9%' ok and can be used with cracks, 'I heard'. Dunno if they would work with bought software too, this might be interesting for people who bought the original and wish to use it on wine. I 'guess' I could get all I need for Windows as a crack, but I don't like cracks and I can't pay for legal versions and I don't wish to have USB dongles. Btw. I don't like the 'philosophy' of Microsoft. While bus dongles using oldish gate chips, are less damageable, I don't trust USB micro controllers. When I was young I tuned my motorbikes and cracked software and used software other people cracked. Juvenile law isn't valid for me today, just one reason not to use cracks. While open sources might not be important to everybody, people also might not care about malign US major corporation, at least keeping our own slates clean is a reason to get Linux more capable for music too. 2 cents, Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Saturday 19 June 2010, Ralf Mardorf wrote: >Hi Gene :) > >Gene Heskett wrote: >> On Saturday 19 June 2010, Ralf Mardorf wrote: >> >> This will go back only to LAD as I'm not subbed to the others, Ralf. >> >>> Ichthyostega wrote: Ralf Mardorf schrieb: > Another stupid question induced by an argument regarding to MIDI > jitter by Daniel James. > >> [snip] I'm sceptical that the realtime kernel is the cause of your >> MIDI problems. If they got this right in the 80's, on computers >> which could not do anything near realtime audio processing, then I >> think it's more likely to be a question of MIDI application design. At that point we should call back, how that whole story with "realtime" started. At the begining was a design mismatch. Many things related to the Linux kernel started out with a kind of "I feel fine" pragmatism. Which, btw isn't to criticise as it is, because this also accounts for the freshness and sometime unconventional new approach to some problems. But with regards to timings, for all of the first decade of Linux development, there seemed to be a completely different mental model, which we could summarise as: permormance == throughput, and timings are only relevant, when you get a network timeout, or a sluggish response in your application's GUI. Thus, if we now consider to use a Linux kernel for making music, we must assess that the whole design isochronously assumed about 1000 times more headroom as there really is. Thus, as writing a new Kernel doesn't seem to be an option, this whole tedious undertaking of the "realtime patches" can be described as an attempt to fix this "problem" (which was never assumed to be a problem in the initial design) by hunting down one by one each individual instance where the existing kernel could possibly be reacting too slow. Thus, we should rather be surprised, how good these realtime kernels work. OTOH, is isn't a surprise the machines from the 80s meet these criteria; their OS software was written with an awareness for a much more limited processing capability right from start. > Why do people (not only me) report jitter for external MIDI > equipment, but I couldn't find any report for real-time audio jitter? > Resp. what's about async and disconnecting clients by JACK? Audio and MIDI are two quite different beasts. Sound is processed in Blocks, where the individual unity (1 Sample) is much more fine grained and way below anything which can be discerned by a human ear. Moreover, Sound as such already exists and 'just' has to be piped through. To the contrary, MIDI consists of events, which immediately trigger a reaction, which could be that a piece of software and at the same time a piece of external hardware starts a processing cycle. You see, thats a completely different situation and thus it's obvious, why for these two media the same problem causes so different symptoms. > OTOH on Windows audio clients don't disconnect, > just MIDI jitter is an issue too. IIRC, this was a design decision for JACK. It never tries to conceal any timeout problem, rather it requires its clients to keep up with a very tight schedule and comply to very strict rules. I don't know the MIDI part of Jack well enough to judge, if it was designed with the same "you're required to comply" policy. And besides, when the MIDI interface is hooked up via USB, we again face a completely different situation. USB is a complicated protocol, which multiple versions and levels and is certainly not designed to get an individual event transfered reliably with less than 2ms jitter. There is even the possibility that the USB peers negotiate to use a lower transfer rate or protocol version transparently, when they determine the connection can't keep up with the higher speed. Cheers Hermann V. >>> >>> It's said that USB MIDI interfaces should be the better choice. But >>> this explains a lot. Dunno how to read Fons JACK MIDI jitter test, but >>> ... >> >> On the face of it, and reading the USB specs, USB would seem to be a >> poor choice for midi unless it re-clocks everything.before sending it >> out the MIDI port. Usb has a 10 millisecond worst case lag in the >> specs. > >To bad that there isn't a MPU game port any more on modern boards and >that e.g. my Terratec EWX 24/96 Envy24's MPU needs opto-couplers for the >cable, but what ever circuit I build on a brad board, they failed. >Time to mount my old mobo again and to test the game ports MPU with >today Linux, resp. to get a service manual for my Terratec. > >>> Subject:Re: [LAD] Again MIDI jitter - tested with Fons test >>> applications Date: Sat, 27 Mar 2010 18:26:33 +0100 >>> From: Ralf Mar
Re: [LAD] [64studio-users] MIDI jitter
On Saturday 19 June 2010, Ralf Mardorf wrote: >Gene Heskett wrote: [...] >The Steinberg dongle seems to be ok, since it's from the 80ies or >beginning 90ies and was used for several years without getting broken. >But exactly because it's that old I fear it could break one day. > >I 'guess' that I also could get cracked versions of Cubase for the >Atari, but while the dongle version is 100% stable and the latest >version ever made for the Atari, there aren't cracks for the latest >version and the cracks I know were '99%' stable. Since most of those dongles back then were themselves protected by grinding the part numbers off the chip, that damage to the expoxy-B covering is probably largely responsible for their short life, both from the instant heating caused by the grinding, but also from moisture migrating into the assembly through the damaged epoxy-B coating. >For Windows there are dongle hacks available by torrent, they do work >'99,9%' ok and can be used with cracks, 'I heard'. Dunno if >they would work with bought software too, this might be interesting for >people who bought the original and wish to use it on wine. > >I 'guess' I could get all I need for Windows as a crack, but I don't >like cracks and I can't pay for legal versions and I don't wish to have >USB dongles. Btw. I don't like the 'philosophy' of Microsoft. >While bus dongles using oldish gate chips, are less damageable, I don't >trust USB micro controllers. >When I was young I tuned my motorbikes and cracked software and used >software other people cracked. Juvenile law isn't valid for me today, >just one reason not to use cracks. And when I was a juvenile, transistors had not been invented yet. ;-) >While open sources might not be important to everybody, people also >might not care about malign US major corporation, at least keeping our >own slates clean is a reason to get Linux more capable for music too. Naw, I'm not the least bit allergic to tweaking the M$ nose. :) Their little 'easter eggs' that cause the loss of an important file that can only be replaced by purchasing a new copy of the os, in this case NT-4.0, have bit me enough times that I have no respect for M$ for about 20 years now. My limited experience with XP showed that it did work, but never felt like a true os to me, just patches to DOS. Their most stable was 95, it ran for 46 days at a time, till the tick counter rolled over. Reboot on day 45 and everything was cool. I would have to assume that DOS-6.22 also suffered from that, we had one of those that crashed about every month & a half but never had the clues to point a finger at that. Just one of those things... >2 cents, Mine too. But I'd imagine the list people are about to police us, this is sort of off topic. ;( >Ralf > -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Q: How do you fix all Windows bugs at once? A: Type DELTREE C:\WINDOWS ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Sat, Jun 19, 2010 at 7:16 AM, Ralf Mardorf wrote: > To bad that there isn't a MPU game port any more on modern boards and that > e.g. my Terratec EWX 24/96 Envy24's MPU needs opto-couplers for the cable, > but what ever circuit I build on a brad board, they failed. > Time to mount my old mobo again and to test the game ports MPU with today > Linux, resp. to get a service manual for my Terratec. http://github.com/koppi/alsa-midi-latency-test gives definite figures showing MPU-401 and Envy24 based MIDI is much faster than USB midi. Makes sense given there's no USB stack to traverse, and there's probably a direct PCI-bus interrupt generated by MIDI data, orchestrated by the plays-nice-with Linux ICE1712/1724 series ( http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf ) which efficiently implements PCI 2.1 bus-master and burst modes, though I'm not sure if that would be used or needed for MIDI. What's interesting to note is that most of the USB MIDI interfaces do not have consistent latency (Other than the Roland UM2's consistent 2.15ms) whereas MPU-401 (1.13mS) and VT1712 (0.97-1.04mS) have this consistency. In contrast an M-audio midisport USB has latency ranging from 3.11-5.38 ms ==> 2ms "jitter" just in the hardware alone, with the jitter being greater than the total latency of a MPU401 or ICE1724-based MIDI. Did I ever mention that firewire and USB are probably the most bone-headed way of doing low-latency audio ever thought of? It begs failure both in theory and practice. But since people following fashion are the quickest lemmings to fall off the cliff (fashion-following being the losing end of a ponzi scheme), the Linux community can benefit from their stupidity: With lots of people moving to USB and Firewire configurations, E-bay is full of used ICE1712 or ICE1724-based soundcards, many of which have MIDI ports, and some which have waveblaster headers. For example the VT1712-based $20.00 Terratec DMX6Fire with a front midi port and an internal 26 pin waveblaster header for my Yamaha db50xg (NEC XR385). Or the VT1723-based $0.99 Dynex dx-sc51 with a single 26 pin waveblaster MIDI port (TTL level MIDI in and out). The only thing lacking on these ten year old designs are a modern A/D and D/A section and analog section, which is why I started the following threads on LAU: http://old.nabble.com/digital-upgrade-of-older-equipment-via-I2S-with-jitter-attenuating-S-PDIF-receiver-evaluation-boardto28997419.html http://old.nabble.com/turning-a-consumer-soundcard-into-%22prosumer%22-w--quasi-balanced-outs-tp28791831p29011212.html Bottom line: MIDI implementation on the ICE VT1712 is faster than an MPU-401 and both are faster than the quickest USB implementation: http://github.com/koppi/alsa-midi-latency-test/blob/master/benchmarks/m-audio-2496.txt (ICE vt1712 soundchip, also using realtime prio) . $ alsa-midi-latency-test -R -i 20:0 -o 20:0 alsa-midi-latency-test 0.0.3 set_realtime_priority(SCHED_FIFO, 99).. done. clock resolution: 0.1 s [...] latency distribution: 1.0 - 1.1 ms:1 ## [...] best latency was 0.97 ms worst latency was 1.04 ms, which is great . http://github.com/koppi/alsa-midi-latency-test/blob/master/benchmarks/mpu401.txt .. latency distribution: [...] 1.0 - 1.1 ms: 3714 ## 1.1 - 1.2 ms: 6286 ## [...] worst latency was 1.13 ms, which is great. ... http://github.com/koppi/alsa-midi-latency-test/blob/master/benchmarks/um2ex.txt ... latency distribution: [...] 1.1 - 1.2 ms:3 # 1.2 - 1.3 ms: 19 # 1.3 - 1.4 ms: 13 # 1.4 - 1.5 ms: 23 # 1.5 - 1.6 ms: 88 # 1.6 - 1.7 ms: 14 # 1.7 - 1.8 ms: 16 # 1.8 - 1.9 ms: 20 # 1.9 - 2.0 ms: 17 # 2.0 - 2.1 ms: 9773 ## 2.1 - 2.2 ms: 13 # [...] worst latency was 2.15 ms, which is great. ... -- Niels http://nielsmayer.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Tue, 2010-06-29 at 18:20 -0700, Niels Mayer wrote: > TTL level MIDI in and out Assumed it's not broken, than for my Terratec EWX 24/96 there's an issue for the pin allocation. Do the ports for most sound cards usually have the common pin allocation? My ASUS M2A-VM HDMI has got 1 x PCI Express x16 formerly used for HDMI, now for a GeForce 7200 GS 1 x PCI Express x1 slot unused 2 x PCI one unused, the other for the Terratec EWX 24/96 Mounting an additional sound card won't cause an issue because of an additional interrupt? There will be no issues, e.g. for JACK, if I would use the Terratec EWX 24/96 for audio and another sound card for MIDI? So USB MIDInterfaces are for bulk dump only ;)? :) Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
I don't know anything about the terratec as I bought my first (used) card manufactured by them recently: they're almost mercedes-like in their overengineering of things (super high quality circuit board and engineering) and the documentation is always sparse... perhaps there's a hidden jumper that sets the mode of the header socket?? Just like my DMX6Fire has a "digital xtension" socket into which you can plugin a waldorf microwave synth module and i'd love to find out the i2s data input and output pinouts so as to replace the analog frontend w/ a few of these http://www.twistedpearaudio.com/digital/wm8804.aspx and gain extra digital ins/outs in place of not-so-great-sounding analog front-end (alas using essentially the same components as on the ewx 24/96 on the dmx6fire 24/96, essentially terratec's version of m-audio's 24/96 and Delta-66). But the built-in, software controlled switch (envy24control) between TTL-spdif, optical-spdif and coax-spdif all but makes up for the analog front end... as do the two full-speed midi ports, one driving my db50xg clone. http://www.soundonsound.com/sos/apr01/articles/soundcard.asp ## On the circuit board itself is a 16-pin header socket, which connects to a ## supplied cable terminating in a dummy backplate and 15-way D-type connector. ## Into this you can either plug a standard MIDI soundcard adaptor cable, or a proprietary ## Terratec phono preamp to help transfer vinyl to CD, both of which are optional extras. > ASUS M2A-VM HDMI... Mounting an additional sound card won't cause an issue > because of an > additional interrupt? It shouldn't, or at least it hasn't for me using similar hardware (M2N-68VM for example). > There will be no issues, e.g. for JACK, if I would use the Terratec EWX > 24/96 for audio and another sound card for MIDI? Just be sure you like the sound of the terratec's weak-sounding bass assuming it sounds similar to the dmx6fire's using the same parts and probably design (which could imho easily be modded back to decency, see sound files for comparison at end of .http://linuxaudio.org/mailarchive/lau/2010/6/28/170833 ) The other card's MIDI devices should just appear as a separate ALSA MIDI device. ALSA midi will function independent of whether jack is running or not, and independent of which soundcard is used for jack-audio. If you need to have jack-audio work across two cards, that's another matter entirely: they'd best be the same kind of card, and have their SPDIF used-up for syncing between them. And I'm ignoring jack-midi entirely , as I don't use it that much; qjackctl's patchbay integration of ALSA midi devices makes jack midi a bit superfluous for my uses. Niels http://nielsmayer.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Tue, 2010-06-29 at 23:42 -0700, Niels Mayer wrote: > I don't know anything about the terratec as I bought my first (used) > card manufactured by them recently: they're almost mercedes-like in > their overengineering of things (super high quality circuit board and > engineering) and the documentation is always sparse... perhaps there's > a hidden jumper that sets the mode of the header socket?? Just like my > DMX6Fire has a "digital xtension" socket into which you can plugin a > waldorf microwave synth module and i'd love to find out the i2s data > input and output pinouts so as to replace the analog frontend w/ a few > of these http://www.twistedpearaudio.com/digital/wm8804.aspx and gain > extra digital ins/outs in place of not-so-great-sounding analog > front-end (alas using essentially the same components as on the ewx > 24/96 on the dmx6fire 24/96, essentially terratec's version of > m-audio's 24/96 and Delta-66). But the built-in, software controlled > switch (envy24control) between TTL-spdif, optical-spdif and coax-spdif > all but makes up for the analog front end... as do the two full-speed > midi ports, one driving my db50xg clone. > > http://www.soundonsound.com/sos/apr01/articles/soundcard.asp > ## On the circuit board itself is a 16-pin header socket, which connects to a > ## supplied cable terminating in a dummy backplate and 15-way D-type > connector. > ## Into this you can either plug a standard MIDI soundcard adaptor > cable, or a proprietary > ## Terratec phono preamp to help transfer vinyl to CD, both of which > are optional extras. > > > ASUS M2A-VM HDMI... Mounting an additional sound card won't cause an issue > > because of an > > additional interrupt? > > It shouldn't, or at least it hasn't for me using similar hardware > (M2N-68VM for example). > > > There will be no issues, e.g. for JACK, if I would use the Terratec EWX > > 24/96 for audio and another sound card for MIDI? > > Just be sure you like the sound of the terratec's weak-sounding bass > assuming it sounds similar to the dmx6fire's using the same parts and > probably design (which could imho easily be modded back to decency, > see sound files for comparison at end of > .http://linuxaudio.org/mailarchive/lau/2010/6/28/170833 ) I don't like the sound of the Terratec EWX 24/96, but it was for free ;). > The other card's MIDI devices should just appear as a separate ALSA > MIDI device. ALSA midi will function independent of whether jack is > running or not, and independent of which soundcard is used for > jack-audio. If you need to have jack-audio work across two cards, > that's another matter entirely: No no :) what ever sound card I should get, I can live with using one duplex stereo. I would be much more comfortable with 16 audio IOs, but that's not important regarding to the MIDI jitter issue. Thank you. Ok, IIUC jackd hw:blabla is for audio, but for ALSA MIDI there would appear all devices?! > they'd best be the same kind of card, > and have their SPDIF used-up for syncing between them. And I'm > ignoring jack-midi entirely , as I don't use it that much; qjackctl's > patchbay integration of ALSA midi devices makes jack midi a bit > superfluous for my uses. > > Niels > http://nielsmayer.com You say I can use my ElCheapo EWX 24/96 with another ElCheapo for audio, by any other vendor, just by connecting S/PDIF to sync the channels? I read about this and I also read about some solutions using my 'roof gutter soldering iron'? I had a champagne breakfast, hence I didn't read the links, I just was curious for your reply. Again, thanx, I'll read the links in the evening. FWIW, there aren't jumpers on the Terratec and I guess the used MPU by the two provided by the EnvyChip is broken. For my old mobo's gameport I soldered an adapter without TTLs and opto-couplers. This cable wasn't fine for the Terratec, hence I took my BreadBoard and checked several circuits, without TTLs, but opto-couplers. While I was a professional using the soldering iron, today I should get glasses. I damaged the jack, because I wasn't able to see what I did solder, so I might be the one who killed the Envy's MPU ;). But maybe they do use some exotic pin allocation. Referring to you, it's more likely that the MPU was broken or that I did break it, because my arms were not long enough for my bad eyes. Ok, I'll get another ElCheapo just for MIDI and solder a usual adapter with or without opto-couplers, but by using a magnifier. The USB MIDI still is usable to dump sounds and it was < 20,-€ at Thomann. To be continued. Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
PS: Don't buy this one http://www.thomann.de/gb/swissonic_midiusb_1x1.htm When I bought it, it costs between 19 and 20 €. It's much better when using it with Windows, but even for Windows it won't fit to the ears of a musician. I deeply suspect the USB MIDI device now causing jitter. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Tue, Jun 29, 2010 at 06:20:30PM -0700, Niels Mayer wrote: > What's interesting to note is that most of the USB MIDI interfaces do > not have consistent latency (Other than the Roland UM2's consistent Let me just show you the result from my Midisport USB 2x2 (standard edition when it was still produced by midiman, not the anniversary edition): set_realtime_priority(SCHED_FIFO, 20).. done. clock resolution: 0.1 s > latency distribution: ... 3.1 - 3.2 ms:1 # ... 3.9 - 4.0 ms:1 # 4.0 - 4.1 ms: 9903 ## ... 5.0 - 5.1 ms: 95 # > SUCCESS best latency was 3.13 ms worst latency was 5.00 ms, which is great. This is a vanilla 2.6.34 kernel, no realtime patches, no nothing. a...@hex:~$ cat /proc/asound/timers G0: system timer : 4000.000us (1000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE P0-1-0: PCM playback 0-1-0 : SLAVE P0-1-1: PCM capture 0-1-1 : SLAVE P0-2-1: PCM capture 0-2-1 : SLAVE Not even HR timers. And yes, this is SMP, and yes, I have the "ondemand" cpu governor, that is, the evil frequency scaling and the lot. Put simply, it's a plain Debian unstable system, no latency tuning at all. Ok, 4ms are not strikingly fast, but it's acceptable and shouldn't matter in praxis. Especially I don't see any noteworthy jitter. I'm going to measure the mainline kernels from 2.6.26 to 2.6.34 within the next days to see if this stability can be accounted to the parts of the RT patch that have been integrated into mainline. If this hypothesis is correct, I should see a lot of jitter with older kernels. I'll also try to compare it against an onboard MPU-401, a firewire based device and one or two more USB solutions. Long story short: Seems things are not black (USB) and white (PCI). -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Wed, Jun 30, 2010 at 02:27:09PM +0200, Adrian Knoth wrote: > Let me just show you the result from my Midisport USB 2x2 (standard > edition when it was still produced by midiman, not the anniversary > edition): > > set_realtime_priority(SCHED_FIFO, 20).. done. > clock resolution: 0.1 s > > > latency distribution: > ... > 3.1 - 3.2 ms:1 # > ... > 3.9 - 4.0 ms:1 # > 4.0 - 4.1 ms: 9903 ## > ... > 5.0 - 5.1 ms: 95 # > > > SUCCESS > > best latency was 3.13 ms > worst latency was 5.00 ms, which is great. I've no idea how this test works, but if it uses the same interface for TX an RX the results should be treated with a healthy dose of scepticism. To be really reliable, the transmitter and receiver should be on different machines. Measuring absolute latency can be difficult in the case (but not impossible) but jitter is easy. Ciao, -- FA O tu, che porte, correndo si ? E guerra e morte ! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
Adrian Knoth wrote: >> latency distribution: > ... > 3.1 - 3.2 ms:1 # > ... > 3.9 - 4.0 ms:1 # > 4.0 - 4.1 ms: 9903 ## > ... > 5.0 - 5.1 ms: 95 # The default parameters of this tool are unrealistic; the next MIDI command is always sent immediately after the previous one has been received, which tends to align everything to USB frames. Please use the -w and -r options. Regards, Clemens ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Wed, 2010-06-30 at 14:27 +0200, Adrian Knoth wrote: > On Tue, Jun 29, 2010 at 06:20:30PM -0700, Niels Mayer wrote: > > > What's interesting to note is that most of the USB MIDI interfaces do > > not have consistent latency (Other than the Roland UM2's consistent > > Let me just show you the result from my Midisport USB 2x2 (standard > edition when it was still produced by midiman, not the anniversary > edition): > > set_realtime_priority(SCHED_FIFO, 20).. done. > clock resolution: 0.1 s > > > latency distribution: > ... > 3.1 - 3.2 ms:1 # > ... > 3.9 - 4.0 ms:1 # > 4.0 - 4.1 ms: 9903 ## > ... > 5.0 - 5.1 ms: 95 # > > > SUCCESS > > best latency was 3.13 ms > worst latency was 5.00 ms, which is great. > > > This is a vanilla 2.6.34 kernel, no realtime patches, no nothing. > > a...@hex:~$ cat /proc/asound/timers > G0: system timer : 4000.000us (1000 ticks) > P0-0-0: PCM playback 0-0-0 : SLAVE > P0-0-1: PCM capture 0-0-1 : SLAVE > P0-1-0: PCM playback 0-1-0 : SLAVE > P0-1-1: PCM capture 0-1-1 : SLAVE > P0-2-1: PCM capture 0-2-1 : SLAVE > > > Not even HR timers. And yes, this is SMP, and yes, I have the "ondemand" > cpu governor, that is, the evil frequency scaling and the lot. Put > simply, it's a plain Debian unstable system, no latency tuning at all. > > Ok, 4ms are not strikingly fast, but it's acceptable and shouldn't > matter in praxis. Especially I don't see any noteworthy jitter. > > I'm going to measure the mainline kernels from 2.6.26 to 2.6.34 within > the next days to see if this stability can be accounted to the parts of > the RT patch that have been integrated into mainline. > > If this hypothesis is correct, I should see a lot of jitter with older > kernels. > > I'll also try to compare it against an onboard MPU-401, a firewire based > device and one or two more USB solutions. > > > Long story short: Seems things are not black (USB) and white (PCI). I'll test PCI as soon as possible too. Btw. while ports from other computers and my whole MIDI hardware is able to use my 80ies self-made MIDI thru box, the level of the USB MIDI's output is to weak to do it (I didn't re-adjust the thru box). Could it be, that a weak level has impact to the interpretation of the slew rate, regarding to high and low? Of course without using this box, because it won't work, I'm thinking of connecting the IOs of the USB MIDI and running the ALSA latency test. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Wed, 2010-06-30 at 14:48 +0200, f...@kokkinizita.net wrote: > I've no idea how this test works, but if it uses the same > interface for TX an RX the results should be treated with > a healthy dose of scepticism. Not only because the system is measuring it self, but also because there is no way to see how much jitter there is for the input and how much jitter there is for the output. Anyway, hw MIDI jitter is audible here and my USB device failed the test, so what I hear, is what the test confirms. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Wed, Jun 30, 2010 at 05:28:05PM +0200, Clemens Ladisch wrote: > >> latency distribution: > > ... > > 3.1 - 3.2 ms:1 # > > ... > > 3.9 - 4.0 ms:1 # > > 4.0 - 4.1 ms: 9903 ## > > ... > > 5.0 - 5.1 ms: 95 # > > The default parameters of this tool are unrealistic; the next MIDI > command is always sent immediately after the previous one has been > received, which tends to align everything to USB frames. Please use > the -w and -r options. Absolutely. I already suspected 4ms being correlated to USB frames (granularity 1ms, right?) With random wait, it looks like this: > latency distribution: ... 3.0 - 3.1 ms: 86 3.1 - 3.2 ms: 986 ## 3.2 - 3.3 ms: 958 # 3.3 - 3.4 ms: 967 # 3.4 - 3.5 ms: 985 ## 3.5 - 3.6 ms: 927 ### 3.6 - 3.7 ms: 966 # 3.7 - 3.8 ms: 938 3.8 - 3.9 ms: 980 ## 3.9 - 4.0 ms: 904 ## 4.0 - 4.1 ms: 906 ## 4.1 - 4.2 ms: 45 ## 4.2 - 4.3 ms: 44 ## 4.3 - 4.4 ms: 38 ## 4.4 - 4.5 ms: 28 # 4.5 - 4.6 ms: 37 ## 4.6 - 4.7 ms: 34 ## 4.7 - 4.8 ms: 54 ### 4.8 - 4.9 ms: 34 ## 4.9 - 5.0 ms: 42 ## 5.0 - 5.1 ms: 40 ## ... 5.2 - 5.3 ms:1 # Probably still acceptable, given that the majority of packets deviates by only 1ms. Does USB have a notion of "ticks" (clock?), that is, frames are sent at isochronous distances? Or is the host controller free to send a packet whenever it wants to? Without the latter, 1ms jitter could be the result of queueing up the data for the next time slot. TIA -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Thursday 01 July 2010, Ralf Mardorf wrote: >On Wed, 2010-06-30 at 14:27 +0200, Adrian Knoth wrote: >> On Tue, Jun 29, 2010 at 06:20:30PM -0700, Niels Mayer wrote: >> > What's interesting to note is that most of the USB MIDI interfaces do >> > not have consistent latency (Other than the Roland UM2's consistent >> >> Let me just show you the result from my Midisport USB 2x2 (standard >> edition when it was still produced by midiman, not the anniversary >> edition): >> >> set_realtime_priority(SCHED_FIFO, 20).. done. >> clock resolution: 0.1 s >> >> > latency distribution: >> >> ... >> 3.1 - 3.2 ms:1 # >> ... >> 3.9 - 4.0 ms:1 # >> 4.0 - 4.1 ms: 9903 >> ## ... >> 5.0 - 5.1 ms: 95 # >> >> > SUCCESS >> >> best latency was 3.13 ms >> worst latency was 5.00 ms, which is great. >> >> >> This is a vanilla 2.6.34 kernel, no realtime patches, no nothing. >> >> a...@hex:~$ cat /proc/asound/timers >> G0: system timer : 4000.000us (1000 ticks) >> P0-0-0: PCM playback 0-0-0 : SLAVE >> P0-0-1: PCM capture 0-0-1 : SLAVE >> P0-1-0: PCM playback 0-1-0 : SLAVE >> P0-1-1: PCM capture 0-1-1 : SLAVE >> P0-2-1: PCM capture 0-2-1 : SLAVE >> >> >> Not even HR timers. And yes, this is SMP, and yes, I have the "ondemand" >> cpu governor, that is, the evil frequency scaling and the lot. Put >> simply, it's a plain Debian unstable system, no latency tuning at all. >> >> Ok, 4ms are not strikingly fast, but it's acceptable and shouldn't >> matter in praxis. Especially I don't see any noteworthy jitter. >> >> I'm going to measure the mainline kernels from 2.6.26 to 2.6.34 within >> the next days to see if this stability can be accounted to the parts of >> the RT patch that have been integrated into mainline. >> >> If this hypothesis is correct, I should see a lot of jitter with older >> kernels. >> >> I'll also try to compare it against an onboard MPU-401, a firewire based >> device and one or two more USB solutions. >> >> >> Long story short: Seems things are not black (USB) and white (PCI). > >I'll test PCI as soon as possible too. >Btw. while ports from other computers and my whole MIDI hardware is able >to use my 80ies self-made MIDI thru box, the level of the USB MIDI's >output is to weak to do it (I didn't re-adjust the thru box). Could it >be, that a weak level has impact to the interpretation of the slew rate, Yes, but this is not the cause of the latency you are looking for. And yes, the current capabilities of the drivers should be brought up to specs to make sure the data doesn't get a scrambled bit occasionally. >regarding to high and low? Of course without using this box, because it >won't work, I'm thinking of connecting the IOs of the USB MIDI and >running the ALSA latency test. Which, because there is the 10ms worst case latency of USB inherent in the standards and connection, will probably show worst cases of at least that. >___ >Linux-audio-dev mailing list >Linux-audio-dev@lists.linuxaudio.org >http://lists.linuxaudio.org/listinfo/linux-audio-dev > -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Save energy: Drive a smaller shell. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
[[see also latency test results for USB 1.0 devices Emagic MT-4 and Edirol UM-2, below reply]] On Wed, Jun 30, 2010 at 12:26 AM, Ralf Mardorf wrote: > You say I can use my ElCheapo EWX 24/96 with another ElCheapo for audio, > by any other vendor, just by connecting S/PDIF to sync the channels? I don't think that is possible, except by luck. I meant two of the same brand/manufacturer cheapo cards with SPDIF ins, e.g. two or three Delta-66's (nb: no vt17212 midi), to or three Dmx6Fire's (one vt1712 real midi, one ttl midi), or Audiophile 24/96's (one vt1712 real midi) It is possible that you could do this with multiple cards all using snd-ice1712 -- because anything's possible and you have the sourcecode to the drivers... :-) > FWIW, there aren't jumpers on the Terratec and I guess the used MPU by > the two provided by the EnvyChip is broken. For my old mobo's gameport I > soldered an adapter without TTLs and opto-couplers. This cable wasn't > fine for the Terratec, hence I took my BreadBoard and checked several > circuits, without TTLs, but opto-couplers. One big issue is that real MIDI is a current-loop interface, with the optocoupler allowing completely independent circuits to be connected w/o creating ground loops and less potential to induce noise from other connected machines. Devices expecting a current-loop are not going to function properly when given TTL levels. You could probably fake something up w/ TTL bus-drivers, but what's the point -- there's probably a zillion game cable ports available for sale uses -- FYI, regarding MIDI latency: some USB tests first (since the 1712-basedDMX6Fire is now waiting for a machine to house it). Note that each test doesn't have a lot of variation, but there are single outliers that indicate the potential for a very occasional few extra ms of jitter. Note that jitter is additive... in that if you're trying to come up with worst-case timing specifications, you need to add all the best cases observed to come up with the overall best case, and all the worst cases observed to come up with an overall worst case. As you add layers and multiple devices all "chained" you can end up with a massive "jitter multiplication effect" where you can't hear any of the individual worst cases, but they'll all manage to coalesce into the worst case -- usually just in time for an important demo/concert/software-release/etc. One of the other properties of jitter is that it likes to stay dormant until something really important is going to fail because you didn't take it into account. Trimming out jitter at the device or OS level is certainly worthwhile given jitter's additive properties. Add enough worst case hardware jitters, worst-case kernel latency and jitter, application level latency and jitter, and you could easily come up with a jitter value that is within human ranges of perception. The test confirms that Emagic's USB Midi devices work as well spec-wise as they do physically (a highly recommended USB MIDI box -- cost about $25.00 on e-bay, vs. $30.00 for the UM-2 with two fewer output ports). Using: > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.1 s On host using ASUS M4A78T-E motherboard and AMD Phenom-II processor running stock Fedora 12 kernel: > Linux gnulem 2.6.32.14-127.fc12.x86_64 #1 SMP Fri May 28 04:30:39 UTC 2010 > x86_64 x86_64 x86_64 GNU/Linux A) Edirol UM-2 ( http://qbik.ch/usb/devices/showdev.php?id=1244 ) (NB: tested using an illegally-long 30-foot USB cable -- that works fine with the UM-2 slow USB device). Device: 36:0UM-2 UM-2 MIDI 1 Command: alsa-midi-latency-test -w -r -R -i 36:0 -o 36:0 Test1) ... 2.5 - 2.6 ms:1 # ... 2.9 - 3.0 ms: 61 # 3.0 - 3.1 ms: 9938 ## best latency was 2.46 ms worst latency was 3.03 ms, which is great. Test2) ... 2.9 - 3.0 ms: 61 # 3.0 - 3.1 ms: 9938 ## ... 4.0 - 4.1 ms:1 # best latency was 2.88 ms worst latency was 4.00 ms, which is great. Test3) ... 2.7 - 2.8 ms:1 # ... 2.9 - 3.0 ms: 60 # 3.0 - 3.1 ms: 9938 ## ... 4.0 - 4.1 ms:1 # best latency was 2.69 ms worst latency was 4.00 ms, which is great. Test4) ... 2.7 - 2.8 ms:1 # ... 2.9 - 3.0 ms: 60 # 3.0 - 3.1 ms: 9939 ## best latency was 2.73 ms worst latency was 3.03 ms, which is great. -- B) Emagic MT-4 ( http://qbik.ch/usb/devices/showdev.php?id=3171 ) Device: 28:0MT4 MT4 MIDI 1 Command: alsa-midi-latency-test -w -r -R -i 28:0 -o 28:0 Test1) ... 1.5 - 1.6 ms:2 # ..
Re: [LAD] [64studio-users] MIDI jitter
On Thu, Jul 1, 2010 at 7:31 PM, Niels Mayer wrote: > [[see also latency test results for USB 1.0 devices Emagic MT-4 and > Edirol UM-2, below reply]] just for comparison, here are the results for an RME Digiface: sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000999848 s > sampling 1 midi latency values - please wait ... > press Ctrl+C to abort test sample; latency_ms; latency_ms_worst 0; 1.00; 1.00 3; 1.00; 1.00 16; 2.00; 2.00 2530; 2.00; 2.00 ; 1.00; 2.00 > done. > latency distribution: 0.0 - 0.1 ms:3 # ... 1.0 - 1.1 ms: 9787 ## ... 2.0 - 2.1 ms: 210 # > SUCCESS best latency was 0.00 ms worst latency was 2.00 ms, which is great. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Thu, Jul 01, 2010 at 07:43:38PM -0400, Paul Davis wrote: > > [[see also latency test results for USB 1.0 devices Emagic MT-4 and > > Edirol UM-2, below reply]] > > just for comparison, here are the results for an RME Digiface: > sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0 You're both missing an argument after -w. I wonder (but haven't checked the source) why the tool even starts when you don't provide the value for the wait time. Niels, you need to re-evaluate everything, too, your data is also aligned to USB frames as pointed out by Clemens two days ago. I use -w 20 -r now, alsa-midi-latency-test then prints out a message like "interval between measurements: 20.000 .. 40.000 ms". HTH -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Fri, Jul 2, 2010 at 6:12 AM, Adrian Knoth wrote: > On Thu, Jul 01, 2010 at 07:43:38PM -0400, Paul Davis wrote: > >> > [[see also latency test results for USB 1.0 devices Emagic MT-4 and >> > Edirol UM-2, below reply]] >> >> just for comparison, here are the results for an RME Digiface: >> sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0 > > You're both missing an argument after -w. I wonder (but haven't > checked the source) why the tool even starts when you don't provide the > value for the wait time. New results: sudo /usr/bin/alsa-midi-latency-test -w 20 -r -R -i 20:0 -o 20:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000999848 s > interval between measurements: 20.000 .. 40.000 ms > sampling 1 midi latency values - please wait ... > press Ctrl+C to abort test sample; latency_ms; latency_ms_worst 0; 1.00; 1.00 6; 1.00; 1.00 ; 1.00; 1.00 > done. > latency distribution: 0.0 - 0.1 ms:4 # ... 1.0 - 1.1 ms: 9996 ## > SUCCESS best latency was 0.00 ms worst latency was 1.00 ms, which is great. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Friday 02 July 2010, Paul Davis wrote: >On Fri, Jul 2, 2010 at 6:12 AM, Adrian Knoth wrote: >> On Thu, Jul 01, 2010 at 07:43:38PM -0400, Paul Davis wrote: [...] >> You're both missing an argument after -w. I wonder (but haven't >> checked the source) why the tool even starts when you don't provide the >> value for the wait time. > >New results: > >sudo /usr/bin/alsa-midi-latency-test -w 20 -r -R -i 20:0 -o 20:0 > Hmm, I'm on mdv-2010-x64 at the moment, what package would I find this test utility in? Thanks. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) The man who can smile when something goes wrong has thought of someone he can blame it on -- Fundamental Law of Thermodynamics n�3 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
Here's the new results with "-w 20" (nb: "-w" == "-w 0") On Thu, Jul 1, 2010 at 4:31 PM, Niels Mayer wrote: > A) Edirol UM-2 ( http://qbik.ch/usb/devices/showdev.php?id=1244 ) > (NB: tested using an illegally-long 30-foot USB cable -- that works > fine with the UM-2 slow USB device). > Device: 36:0UM-2 UM-2 MIDI 1 sudo alsa-midi-latency-test -w 20 -r -R -i 36:0 -o 36:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.1 s > interval between measurements: 20.000 .. 40.000 ms ... Test1) 2.0 - 2.1 ms:2 # 2.1 - 2.2 ms: 485 2.2 - 2.3 ms: 995 # 2.3 - 2.4 ms: 1010 # 2.4 - 2.5 ms: 1007 # 2.5 - 2.6 ms: 976 2.6 - 2.7 ms: 1000 # 2.7 - 2.8 ms: 981 2.8 - 2.9 ms: 1021 ## 2.9 - 3.0 ms: 950 ## 3.0 - 3.1 ms: 1025 ## 3.1 - 3.2 ms: 547 ### 3.2 - 3.3 ms:1 # best latency was 2.03 ms worst latency was 3.19 ms, which is great. Test2) 2.1 - 2.2 ms: 500 # 2.2 - 2.3 ms: 1000 # 2.3 - 2.4 ms: 1003 # 2.4 - 2.5 ms: 1007 # 2.5 - 2.6 ms: 978 2.6 - 2.7 ms: 1004 # 2.7 - 2.8 ms: 991 # 2.8 - 2.9 ms: 1010 ## 2.9 - 3.0 ms: 951 ### 3.0 - 3.1 ms: 1018 ## 3.1 - 3.2 ms: 538 ## best latency was 2.07 ms worst latency was 3.11 ms, which is great. > B) Emagic MT-4 ( http://qbik.ch/usb/devices/showdev.php?id=3171 ) > Device: 28:0 MT4 MT4 MIDI 1 sudo alsa-midi-latency-test -w 20 -r -R -i 28:0 -o 28:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.1 s > interval between measurements: 20.000 .. 40.000 ms Test1) 1.2 - 1.3 ms:1 # 1.3 - 1.4 ms: 727 ### 1.4 - 1.5 ms: 1017 # 1.5 - 1.6 ms: 973 ## 1.6 - 1.7 ms: 1007 1.7 - 1.8 ms: 981 ### 1.8 - 1.9 ms: 1021 # 1.9 - 2.0 ms: 944 # 2.0 - 2.1 ms: 1019 # 2.1 - 2.2 ms: 1048 ## 2.2 - 2.3 ms: 993 ### 2.3 - 2.4 ms: 268 # 2.4 - 2.5 ms:1 # best latency was 1.18 ms worst latency was 2.37 ms, which is great. Test2) 1.2 - 1.3 ms:3 # 1.3 - 1.4 ms: 710 ## 1.4 - 1.5 ms: 1016 1.5 - 1.6 ms: 978 ## 1.6 - 1.7 ms: 1001 1.7 - 1.8 ms: 995 ### 1.8 - 1.9 ms: 1010 1.9 - 2.0 ms: 947 # 2.0 - 2.1 ms: 1023 # 2.1 - 2.2 ms: 1053 ## 2.2 - 2.3 ms: 1004 2.3 - 2.4 ms: 260 best latency was 1.19 ms worst latency was 2.33 ms, which is great. ... -- Niels http://nielsmayer.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Fri, 2010-07-02 at 09:51 -0400, Gene Heskett wrote: > Hmm, I'm on mdv-2010-x64 at the moment, what package would I find this test > utility in? Hi Gene :) install (debhelper) autotools-dev automake libasound2-dev $ git clone git://github.com/koppi/alsa-midi-latency-test.git $ cd alsa-midi-latency-test $ sh autogen.sh $ ./configure # checkinstall (or # make install) # make clean Cheers! Ralf -- "Suse 11.2 - Proprietärer NVIDIA-Treiber Beitrag von stachelmaus » 3. Jul 2010, 12:48 Hi :) für einen selbst gebauten Kernel 2.6.31.6-rt19 x86_64 habe ich den proprietären NVIDIA Treiber installiert, für den neueren selbst gebauten Kernel 2.6.33.5-rt23 x86_64 versuche ich nun ausschließlich das Modul zu bauen, doch es funktionierte bisher nicht. Der wesentliche Auszug aus /var/log/nvidia-installer.log ist wahrscheinlich "[...] test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo; \ echo " ERROR: Kernel configuration is invalid."; \ echo " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo " Run 'make oldconfig && make prepare' on kernel src to fix it.[...]". Das ausführen von make oldconfig && make prepare hat nichts gebracht, bzw. existieren die Dateien include/generated/autoconf.h und include/config/auto.conf im Kernel src samt Inhalten. Wozu es auch immer gut sein mag, den Kernel 2.6.31.6-rt19 gebootet habe ich es u.a. mit sh ./NVIDIA*.run -a --no-questions -K --kernel-name=2.6.33.5-rt23 und den Kernel 2.6.33.5-rt23 gebootet u.a. mit sh ./NVIDIA*.run -a -K versucht. Der natürlich nicht aktualisierte Installer für eine GeForce 7200 GS ist NVIDIA-Linux-x86_64-195.36.15-pkg2.run. Grüße Ralf" (http://www.linux-club.de/viewtopic.php?f=48&t=110034) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Fri, 2010-07-02 at 14:51 -0700, Niels Mayer wrote: > sudo alsa-midi-latency-test -w 20 -r -R -i 36:0 -o 36:0 Perhaps better without sudo. -- "Suse 11.2 - Proprietärer NVIDIA-Treiber Beitrag von stachelmaus » 3. Jul 2010, 12:48 Hi :) für einen selbst gebauten Kernel 2.6.31.6-rt19 x86_64 habe ich den proprietären NVIDIA Treiber installiert, für den neueren selbst gebauten Kernel 2.6.33.5-rt23 x86_64 versuche ich nun ausschließlich das Modul zu bauen, doch es funktionierte bisher nicht. Der wesentliche Auszug aus /var/log/nvidia-installer.log ist wahrscheinlich "[...] test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo; \ echo " ERROR: Kernel configuration is invalid."; \ echo " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo " Run 'make oldconfig && make prepare' on kernel src to fix it.[...]". Das ausführen von make oldconfig && make prepare hat nichts gebracht, bzw. existieren die Dateien include/generated/autoconf.h und include/config/auto.conf im Kernel src samt Inhalten. Wozu es auch immer gut sein mag, den Kernel 2.6.31.6-rt19 gebootet habe ich es u.a. mit sh ./NVIDIA*.run -a --no-questions -K --kernel-name=2.6.33.5-rt23 und den Kernel 2.6.33.5-rt23 gebootet u.a. mit sh ./NVIDIA*.run -a -K versucht. Der natürlich nicht aktualisierte Installer für eine GeForce 7200 GS ist NVIDIA-Linux-x86_64-195.36.15-pkg2.run. Grüße Ralf" (http://www.linux-club.de/viewtopic.php?f=48&t=110034) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
PS: Perhaps you need to install git-core too. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
> PS: Perhaps you need to install git-core too. And libtool. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Saturday 03 July 2010, Ralf Mardorf wrote: >On Fri, 2010-07-02 at 14:51 -0700, Niels Mayer wrote: >> sudo alsa-midi-latency-test -w 20 -r -R -i 36:0 -o 36:0 > >Perhaps better without sudo. > Probably, as that will test the user environment. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Q: What do you call the scratches that you get when a female sheep bites you? A: Ewe nicks. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
2010/7/3 Ralf Mardorf : > On Fri, 2010-07-02 at 14:51 -0700, Niels Mayer wrote: >> sudo alsa-midi-latency-test -w 20 -r -R -i 36:0 -o 36:0 > > Perhaps better without sudo. I was just following Paul Davis' lead (*). For me, there's probably no need for this, as my user 'npm' has membership in group jackuser spec'd in /etc/security/limits.conf : > ## Automatically appended by the Planet CCRMA jack-audio-connection-kit > ## NPM changed '*' to @jackuser to limit priority escalation to jackd. > @jackuser - rtprio 99 > @jackuser - memlock 4194304 > @jackuser - nice -10 And /etc/group has entries like: > jackuser:x:476:npm > rtkit:x:470:npm Running as root sidesteps the need for such setup, as well as any permissions issues on the devices under test. From what I can tell, the only privileged access in the test program is indicated by the following output from 'alsa-midi-latency-test': > set_realtime_priority(SCHED_FIFO, 99).. done. . (*): On Fri, Jul 2, 2010 at 4:50 AM, Paul Davis wrote: > just for comparison, here are the results for an RME Digiface: > sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0 > ... > best latency was 0.00 ms > worst latency was 1.00 ms, which is great. Better if Paul re-ran the test with "-w 20" argument so his fancypants RME doesn't end up unfairly claiming the 0ms latency title :-) ... Who will claim the low-latency, low-jitter title in this epic battle-of-the-geek: VLSI-implemented midi on the VT1712 or RME's custom FPGA programming?? [[ http://old.nabble.com/Is-RME-HDSPe-AES-supported-by-alsa--td28460997.html ]]. Note that RME's FPGA implemented MIDI and mixer lacks an important feature we get on cheap vt1712 VLSI implementations: MIDI control over the built-in digital mixer via envy24control: http://alsa-tools.sourcearchive.com/documentation/1.0.22-1/midi_8c-source.html (yes there's a built-in midi-controllable, 20 channel, 36-bit digital mixer hidden in that cheap ebay vt1712 -- http://www.via.com.tw/en/products/audio/controllers/envy24/ ). Digital mixing is an important feature of RME's TotalMix : http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_support_techinfo_hdsp_totalmix_hardware But MIDI control of that mixer seems to be lacking in alsa's hdspmixer and RME's implementation: http://www.rme-audio.de/forum/viewtopic.php?id=6105 -- Niels http://nielsmayer.com PS: worlds' cheapest digital mixing console, take old/slow computer, add linux and these: http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=230491593275 http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260501295877 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
There's still an issue with the latest Kernel and my NVIDIA, but on Tuesday I should be able to compare my USB's to my PCI card's MIDI. I guess @jackuser - nice -10 for rt has got no impact. I'm thinking to run the ALSA MIDI latency test without and with hrtimer (hpet) and without and with glxgears running. On Sat, 2010-07-03 at 09:12 -0700, Niels Mayer wrote: > 2010/7/3 Ralf Mardorf : > > On Fri, 2010-07-02 at 14:51 -0700, Niels Mayer wrote: > >> sudo alsa-midi-latency-test -w 20 -r -R -i 36:0 -o 36:0 > > > > Perhaps better without sudo. > > I was just following Paul Davis' lead (*). > > For me, there's probably no need for this, as my user 'npm' has > membership in group jackuser spec'd in /etc/security/limits.conf : > > > ## Automatically appended by the Planet CCRMA jack-audio-connection-kit > > ## NPM changed '*' to @jackuser to limit priority escalation to jackd. > > @jackuser - rtprio 99 > > @jackuser - memlock 4194304 > > @jackuser - nice -10 > > And /etc/group has entries like: > > > jackuser:x:476:npm > > rtkit:x:470:npm > > Running as root sidesteps the need for such setup, as well as any > permissions issues on the devices under test. From what I can tell, > the only privileged access in the test program is indicated by the > following output from 'alsa-midi-latency-test': > > > set_realtime_priority(SCHED_FIFO, 99).. done. > > . > (*): > On Fri, Jul 2, 2010 at 4:50 AM, Paul Davis wrote: > > just for comparison, here are the results for an RME Digiface: > > sudo /usr/bin/alsa-midi-latency-test -w -r -R -i 20:0 -o 20:0 > > ... > > best latency was 0.00 ms > > worst latency was 1.00 ms, which is great. > > Better if Paul re-ran the test with "-w 20" argument so his fancypants > RME doesn't end up unfairly claiming the 0ms latency title :-) ... > > Who will claim the low-latency, low-jitter title in this epic > battle-of-the-geek: > VLSI-implemented midi on the VT1712 or RME's custom FPGA programming?? > [[ http://old.nabble.com/Is-RME-HDSPe-AES-supported-by-alsa--td28460997.html > ]]. > > Note that RME's FPGA implemented MIDI and mixer lacks an important > feature we get on cheap vt1712 VLSI implementations: > MIDI control over the built-in digital mixer via envy24control: > http://alsa-tools.sourcearchive.com/documentation/1.0.22-1/midi_8c-source.html > (yes there's a built-in midi-controllable, 20 channel, 36-bit digital > mixer hidden in that cheap ebay vt1712 -- > http://www.via.com.tw/en/products/audio/controllers/envy24/ ). > > Digital mixing is an important feature of RME's TotalMix : > http://www.rme-audio.de/en_support_techinfo.php?page=content/support/en_support_techinfo_hdsp_totalmix_hardware > But MIDI control of that mixer seems to be lacking in alsa's hdspmixer > and RME's implementation: > http://www.rme-audio.de/forum/viewtopic.php?id=6105 > > -- Niels > http://nielsmayer.com > > PS: worlds' cheapest digital mixing console, take old/slow computer, > add linux and these: > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=230491593275 > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=260501295877 -- "Suse 11.2 - Proprietärer NVIDIA-Treiber Beitrag von stachelmaus » 3. Jul 2010, 12:48 Hi :) für einen selbst gebauten Kernel 2.6.31.6-rt19 x86_64 habe ich den proprietären NVIDIA Treiber installiert, für den neueren selbst gebauten Kernel 2.6.33.5-rt23 x86_64 versuche ich nun ausschließlich das Modul zu bauen, doch es funktionierte bisher nicht. Der wesentliche Auszug aus /var/log/nvidia-installer.log ist wahrscheinlich "[...] test -e include/generated/autoconf.h -a -e include/config/auto.conf || ( \ echo; \ echo " ERROR: Kernel configuration is invalid."; \ echo " include/generated/autoconf.h or include/config/auto.conf are missing.";\ echo " Run 'make oldconfig && make prepare' on kernel src to fix it.[...]". Das ausführen von make oldconfig && make prepare hat nichts gebracht, bzw. existieren die Dateien include/generated/autoconf.h und include/config/auto.conf im Kernel src samt Inhalten. Wozu es auch immer gut sein mag, den Kernel 2.6.31.6-rt19 gebootet habe ich es u.a. mit sh ./NVIDIA*.run -a --no-questions -K --kernel-name=2.6.33.5-rt23 und den Kernel 2.6.33.5-rt23 gebootet u.a. mit sh ./NVIDIA*.run -a -K versucht. Der natürlich nicht aktualisierte Installer für eine GeForce 7200 GS ist NVIDIA-Linux-x86_64-195.36.15-pkg2.run. Grüße Ralf" (http://www.linux-club.de/viewtopic.php?f=48&t=110034) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Sat, Jul 03, 2010 at 02:32:19PM +0200, Ralf Mardorf wrote: [One line of content] > -- > "Suse 11.2 - Proprietärer NVIDIA-Treiber > Beitrag von stachelmaus » 3. Jul 2010, 12:48 > > Hi :) [this and more than 30 lines of German text about whatever in a signature] For fuck's sake, stop spamming. Nobody is interested in your bloody nvidia stupidity or whatever this "text" is about. There's really no need to include the crap in every mail. Read the netiquette and only come back iff you could be arsed to change your signature into something that's at most four lines long. Damn, where's my prozac? -- mail: a...@thur.de http://adi.thur.de PGP/GPG: key via keyserver ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Sun, 2010-07-04 at 18:45 +0200, Adrian Knoth wrote: > Damn, where's my prozac? When you go wild you shouldn't take selective serotonin reuptake inhibitor, instead try some stimulus retarding tricyclic antidepressants, if you need antidepressants, but tranquilizer. I hope the signature is pleasant now and you are able to watch soccer again and bawl out with the others. -- http://www.linux-club.de/viewtopic.php?f=48&t=110034 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
Niels Mayer wrote: > Here's the new results with "-w 20" (nb: "-w" == "-w 0") > >> A) Edirol UM-2 > > best latency was 2.07 ms > worst latency was 3.11 ms, which is great. As long we're optimizing for benchmarks: In recent enough kernel versions, Roland (Edirol/BOSS) USB MIDI devices have a mixer control "MIDI Input Mode" (the same as the "Light Load" checkbox in the Windows driver) which doesn't have much effect in practice but can improve benchmark behaviour. For bulk transfers (used by Roland devices in "High Load" mode, and always by all other devices), the UHCI driver has a feature called FSBR (full-speed bandwidth reclamation) which makes the controller poll the device continuously instead of every 1 ms, as long as new input is available every 10 ms. So to get better benchmark numbers, use "-w 1" instead of "-w 20". (If your music doesn't have new notes every 10 ms, this isn't very realistic, but it can improve latency between the consecutive notes of a chord.) Regards, Clemens ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Mon, 2010-07-05 at 09:16 +0200, Clemens Ladisch wrote: > Niels Mayer wrote: > > Here's the new results with "-w 20" (nb: "-w" == "-w 0") > > > >> A) Edirol UM-2 > > > > best latency was 2.07 ms > > worst latency was 3.11 ms, which is great. > > As long we're optimizing for benchmarks: In recent enough kernel > versions, Roland (Edirol/BOSS) USB MIDI devices have a mixer control > "MIDI Input Mode" (the same as the "Light Load" checkbox in the Windows > driver) which doesn't have much effect in practice but can improve > benchmark behaviour. > > For bulk transfers (used by Roland devices in "High Load" mode, and > always by all other devices), the UHCI driver has a feature called FSBR > (full-speed bandwidth reclamation) which makes the controller poll the > device continuously instead of every 1 ms, as long as new input is > available every 10 ms. So to get better benchmark numbers, use "-w 1" > instead of "-w 20". (If your music doesn't have new notes every 10 ms, > this isn't very realistic, but it can improve latency between the > consecutive notes of a chord.) > > > Regards, > Clemens I noticed that I run my test without the "-R" switch "alsa-midi-latency-test -i20:0 -o20:0" and Gustin who already used "-w 20 -r" did also miss the "-R" switch, "alsa-midi-latency-test -i 16:0 -o 16:0 -w 20 -r". alsa-midi-latency-test --help -R, --realtime use realtime scheduling (default: no) Did you add "-R"? Cheers! Ralf ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
On Mon, Jul 5, 2010 at 12:16 AM, Clemens Ladisch wrote: > As long we're optimizing for benchmarks: In recent enough kernel > versions, Roland (Edirol/BOSS) USB MIDI devices have a mixer control > "MIDI Input Mode" (the same as the "Light Load" checkbox in the Windows > driver) which doesn't have much effect in practice but can improve > benchmark behaviour. Note that for kernel 2.6.32.14-127.fc12.x86_64, and for ## snd-card-3 snd-usb-audio ## --> Emagic MT4 ## alias snd-card-5 snd-usb-audio ## --> Roland UM-2 ## ## amixer -c 5 --> returns nothing ## amixer -c 3 --> returns nothing Maybe the feature will be present in fedora 13? > For bulk transfers (used by Roland devices in "High Load" mode, and > always by all other devices), the UHCI driver has a feature called FSBR > (full-speed bandwidth reclamation) which makes the controller poll the > device continuously instead of every 1 ms, as long as new input is > available every 10 ms. So to get better benchmark numbers, use "-w 1" > instead of "-w 20". (If your music doesn't have new notes every 10 ms, > this isn't very realistic, but it can improve latency between the > consecutive notes of a chord.) Here's results for the Roland UM-2 with the argument suggested: ## sudo alsa-midi-latency-test -w 1 -r -R -i 36:0 -o 36:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.1 s > interval between measurements: 1.000 .. 2.000 ms Test1) 2.1 - 2.2 ms: 488 2.2 - 2.3 ms: 961 ### 2.3 - 2.4 ms: 1023 ## 2.4 - 2.5 ms: 1030 ## 2.5 - 2.6 ms: 996 2.6 - 2.7 ms: 971 ### 2.7 - 2.8 ms: 952 ## 2.8 - 2.9 ms: 1013 # 2.9 - 3.0 ms: 1025 ## 3.0 - 3.1 ms: 1013 # 3.1 - 3.2 ms: 518 # 3.2 - 3.3 ms:6 # 3.3 - 3.4 ms:1 # ... 3.5 - 3.6 ms:1 # 3.6 - 3.7 ms:1 # ... 3.8 - 3.9 ms:1 # best latency was 2.08 ms worst latency was 3.84 ms, which is great. .. Test2) ... 2.1 - 2.2 ms: 479 ### 2.2 - 2.3 ms: 944 # 2.3 - 2.4 ms: 1034 # 2.4 - 2.5 ms: 1012 2.5 - 2.6 ms: 1006 2.6 - 2.7 ms: 985 ### 2.7 - 2.8 ms: 913 2.8 - 2.9 ms: 1046 ## 2.9 - 3.0 ms: 1021 # 3.0 - 3.1 ms: 1011 3.1 - 3.2 ms: 543 ## 3.2 - 3.3 ms:3 # ... 3.4 - 3.5 ms:2 # 3.5 - 3.6 ms:1 # best latency was 2.07 ms worst latency was 3.55 ms, which is great. Last time, with "-w 20": Test1) best latency was 2.03 ms worst latency was 3.19 ms, which is great. Test2) best latency was 2.07 ms worst latency was 3.11 ms, which is great. -- Niels http://nielsmayer.com ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [64studio-users] MIDI jitter
Niels Mayer wrote: > On Mon, Jul 5, 2010 at 12:16 AM, Clemens Ladisch wrote: > > As long we're optimizing for benchmarks: In recent enough kernel > > versions, Roland (Edirol/BOSS) USB MIDI devices have a mixer control > > "MIDI Input Mode" > > ## alias snd-card-5 snd-usb-audio ## --> Roland UM-2 > ## amixer -c 5 --> returns nothing I forgot to mention that this control appears only when the device's "Advanced Driver" mode is enabled. Regards, Clemens ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
