[linux-audio-dev] [ANN] rtsynth 1.8.0
get the new blue version of rtsynth from: www.linux-sound.org/rtsynth/ enjoy, Stefan P.S. An updated jackified version will follow as soon as i can test it on my machine in RT mode. _ Internet access plans that fit your lifestyle -- join MSN. http://resourcecenter.msn.com/access/plans/default.asp
[linux-audio-dev] [admin] massive spam attack
there has been a massive spam attack against linux-audio-dev yesterday. expect longer round-trip times and even more anal filtering while i'm tracking this down. regards, jörn -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
Re: [linux-audio-dev] [admin] massive spam attack
Joern Nettingsmeier wrote: there has been a massive spam attack against linux-audio-dev yesterday. expect longer round-trip times and even more anal filtering while i'm tracking this down. looks like somebody abused a machine of hostpoint.ch. i was just about to start bitching, but a fingerprinting scan shows it's running linux... goes to show there is no admin-proof operating system. some kid must have subscribed a number of other lists to a mailing list on that server, which generated about 100 spam/hour... the spam seems to have ceased now. just to be sure, i have blackholed both hostpoint.ch and the originating domain blackmusic.ch. best, jörn -- Jörn Nettingsmeier Kurfürstenstr 49, 45138 Essen, Germany http://spunk.dnsalias.org (my server) http://www.linuxdj.com/audio/lad/ (Linux Audio Developers)
Re: [linux-audio-dev] Interesting USB MIDI master keyboards, do they work with Linux ?
Hi, I meant of sending midi events from the master keyboard via USB to the PC which runs an internal soft-synth/sampler. In that case USB should improve timing because of the bigger bandwidth, (but will add 1msec of latency due to USB1 polling mechanism as far as I can understand). Correct me if I'm wrong. cheers, Benno You wrote: - Ok if the Edirol keyboards support standard MIDI then there shouldn't be any problems using them under Linux, but since USB has a much bigger bandwidth than serial MIDI, I that the timing for notes that belong to large chords is more precise. Can someone confirm this ? Not really, unless you are spreading those chords on several separate midi outputs. If it just one, then it determines the bandwidth available. Getting things faster to the interface will do nothing because it still has to send the bytes to the external synth at the same old slow 31250 baud speed. - -- http://linuxsampler.sourceforge.net Building a professional grade software sampler for Linux. Please help us designing and developing it.
[linux-audio-dev] Re: Cheby amp code
found out some interesting facts about the chebyshev. been playing around a little with a chebyshev shaper, feeding it various harmonic amplitudes and a sine oscillation, taking an FT afterward. it seems that in order to get a harmonic of amplitude 0.5, you must not pass 0.5 to chebpc for that harmonic, but sqrt(2)/2. for a harmonic of amplitude .3, pass in sqrt(3)/3, etc. thus, if we want amplitude 'a' for a given harmonic, the chebpc coefficient is 'a * sqrt (1/a)' rather than simply 'a'. (negative amplitudes: ?). the peak value of the chebyshev-shaped output will be the sum of all coefficients calculated in this manner. the further the incoming sine is scaled down (from [-1,+1]), the less the harmonic mix will match the wanted amplitudes. for the amp code, this would mean we should probably try the following: compress/expand the incoming signal to fit exactly into [-1, 1] (normalize). the coefficient tables need some treatment, too -- we want the output sum to be 1, and the relative strengths of the harmonics to match. i'm not up to understanding all implications of the fact that the incoming signal is not a pure sine; neither do i have a recipe for preparing the coefficient tables -- if we scale the individual coefficients by 1/sum their mix will not match what we want. tim
[linux-audio-dev] Re: Cheby amp code
On Sun, Nov 03, 2002 at 05:08:33 +0100, Tim Goetze wrote: the peak value of the chebyshev-shaped output will be the sum of all coefficients calculated in this manner. the further the incoming sine is scaled down (from [-1,+1]), the less the harmonic mix will match the wanted amplitudes. Hmm, I suspect that this sames the cheby unsiutable for what we want, the output from a guitar appears to be far fronm a sin. for the amp code, this would mean we should probably try the following: compress/expand the incoming signal to fit exactly into [-1, 1] (normalize). the coefficient tables need some treatment, too -- we want the output sum to be 1, and the relative strengths of the harmonics to match. i'm not up to understanding all implications of the fact that the incoming signal is not a pure sine; neither do i have a recipe for preparing the coefficient tables -- if we scale the individual coefficients by 1/sum their mix will not match what we want. I think we should probably abandon the cheby approach for now, this combined with the freqency dependency problem probably makes it a looser :( - Steve
[linux-audio-dev] Re: Cheby amp code
On Sat, Nov 02, 2002 at 08:12:10 +0100, Tim Goetze wrote: In the instantaite block fixes it up more-or-less. Maybe even adds a bit of compression (it boosts the gain to make it roughly 1:1 too). have you modified the lut in the meantime? i don't seem to be getting the right results with the log scaling you use. Did you try adding the 0th harmionic to the front of the table, and dropping the last harmonic? That made it sound pretty good for low notes. ah, i'm afraid that's only half the truth. try the link i posted to the list; somebody has been doing this before us and published. i still haven't checked for frequency dependency of valve distortion, but it seems they have, and found it to exist. Figures, on both counts. additionally, it seems that to tackle intermodulation distortion it is best to split the incoming signal to multiple bands (those great theoreticians have been using FIRs in matlab) and shape each band separately. they do in fact use two blended shapers per band. OK, why do they use two shapers? Or is it one cheby and one non polynomial? btw, the 'lower frequency' phenomenon occurs with the real amp, too, only it's not as pronounced. OK, I didn't know that. drat. i fear that we'll need to cool this box into superconductance to get the effect done *really* right. Yeah, I'm thinking we're not tackling it right, if behringer can knock out a virtual amp harware box for E150 it can't the that cycle hungry. - Steve
Re: [linux-audio-dev] Re: Cheby amp code
Steve Harris wrote: On Sun, Nov 03, 2002 at 05:08:33 +0100, Tim Goetze wrote: the peak value of the chebyshev-shaped output will be the sum of all coefficients calculated in this manner. the further the incoming sine is scaled down (from [-1,+1]), the less the harmonic mix will match the wanted amplitudes. Hmm, I suspect that this sames the cheby unsiutable for what we want, the output from a guitar appears to be far fronm a sin. if we normalize the incoming signal, apply the shaper(s), then scale down, it just might work -- it will get the harmonic mix right at least. i'm not up to understanding all implications of the fact that the incoming signal is not a pure sine; neither do i have a recipe for preparing the coefficient tables -- if we scale the individual coefficients by 1/sum their mix will not match what we want. I think we should probably abandon the cheby approach for now, this combined with the freqency dependency problem probably makes it a looser :( yep, it doesn't seem to be getting easier the more we look at it. the above approach could bring us close, but it does need xfading and two chebyshev shapers. been thinking about how to do a hard clipper with sinc some more today, without real results though. tim
Re: [linux-audio-dev] Interesting USB MIDI master keyboards, do theywork with Linux ?
I meant of sending midi events from the master keyboard via USB to the PC which runs an internal soft-synth/sampler. Sorry, I misunderstood. You are right, if the keyboard is connected through usb big chords will have much better timing. The 1msec added latency should not make any difference at all when compared to normal midi. One midi note (no running status) takes about 1msec to be transmitted at 31250 baud. -- Fernando In that case USB should improve timing because of the bigger bandwidth, (but will add 1msec of latency due to USB1 polling mechanism as far as I can understand). Correct me if I'm wrong. cheers, Benno You wrote: - Ok if the Edirol keyboards support standard MIDI then there shouldn't be any problems using them under Linux, but since USB has a much bigger bandwidth than serial MIDI, I that the timing for notes that belong to large chords is more precise. Can someone confirm this ? Not really, unless you are spreading those chords on several separate midi outputs. If it just one, then it determines the bandwidth available. Getting things faster to the interface will do nothing because it still has to send the bytes to the external synth at the same old slow 31250 baud speed.
Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1 + lowlat + preempt + alsa + jack = dead computer
Fernando Pablo Lopez-Lezcano wrote: If I start jackd and then use the freqtweak jack client I get a completely dead machine in a very short time (from a few seconds to 10 or 20 seconds). [...] I get exactly the same results as you. 2.4.19 works fine, 2.4.20-pre10-ac3, 2.5.41 - 2.5.45 lock up. Have you tried anything in between pre10-ac3 and pre4? I know pre4 works fine. I probably should post to the lkml with as much detail as we can get (unless some kernel hacker is actually reading these messages). -- Fernando
Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1 + lowlat + preempt + alsa + jack = dead computer
Fernando Pablo Lopez-Lezcano wrote: Have you tried anything in between pre10-ac3 and pre4? I know pre4 works fine. I probably should post to the lkml with as much detail as we can get (unless some kernel hacker is actually reading these messages). Hmm, it's actually pre10-ac2, there hasn't been an -ac3 yet :-) But to answer your question: yes, I've tried various other 2.4.20 prepatches, but I don't know exactly which ones. All of them had the lockup problem however. regards, Stefan
Re: [linux-audio-dev] Interesting USB MIDI master keyboards, do theywork with Linux ?
Fernando Pablo Lopez-Lezcano wrote: through usb big chords will have much better timing. The 1msec added latency should not make any difference at all when compared to normal midi. One midi note (no running status) takes about 1msec to be transmitted at 31250 baud. there's a difference though: the usb 1 ms is jitter, there's no way to reconstruct the original timing. this in contrast to midi, where you can extrapolate the exact event time quite well (provided you're looking at a stream of mostly isolated events). oh well, most people think 1 ms is below human perception limits anyway. tim
Re: [linux-audio-dev] Interesting USB MIDI master keyboards, do they
work with Linux ? Tim Goetze [EMAIL PROTECTED] writes: there's a difference though: the usb 1 ms is jitter, there's no way to reconstruct the original timing. this in contrast to midi, where you can extrapolate the exact event time quite well (provided you're looking at a stream of mostly isolated events). oh well, most people think 1 ms is below human perception limits anyway. People who are into this topic might want to take a few minutes to review Appendix C.1 (pp 66-70) of the MWPP draft: http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-mwpp.txt It basically describes the three methods MWPP provides for coding timestamps onto MIDI commands when packetizing a MIDI stream. The goal is that whatever your MIDI source is (a MIDI 1.0 DIN jack, an algorithmic composition program, etc), one of these three methods will be the right one to capture the timing as best as can be, into an RTP packet. Feedback is welcome on the topic, we're starting to close in Last Call for the document, but there is still a few months left ... - John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro -
Re: [linux-audio-dev] Re: [Jackit-devel] 2.4.20-rc1 + lowlat + preempt + alsa + jack = dead computer
Fernando Pablo Lopez-Lezcano wrote: Have you tried anything in between pre10-ac3 and pre4? I know pre4 works fine. I probably should post to the lkml with as much detail as we can get (unless some kernel hacker is actually reading these messages). Does it fail with 2.4.20-pre5? I've found a changelog entry for pre5 that looks like it might have something to do with the problem. [EMAIL PROTECTED]: o Fix scheduler's RT behaviour regards, Stefan -- http://www.shockfrosted.org
[linux-audio-dev] Re: Cheby amp code
On Sun, Nov 03, 2002 at 07:48:55 +0100, Tim Goetze wrote: OK, why do they use two shapers? Or is it one cheby and one non polynomial? two chebyshevs, blend factor depending on incoming amplitude. Thats interesting, cos liiing at your waterfall plot it doesn;t seem liek that should be enough. Yeah, I'm thinking we're not tackling it right, if behringer can knock out a virtual amp harware box for E150 it can't the that cycle hungry. funny; now that i'm losing some skepticism about the approach you seem to pick it up. I odnt think that Line 6 and co. are using chebys, I think there using something more like our first attempt. That's not based on any knowledge or anything, just a hunch. - Steve
Re: [linux-audio-dev] Re: Cheby amp code
On Sun, Nov 03, 2002 at 08:06:53 +0100, Tim Goetze wrote: i'm not up to understanding all implications of the fact that the incoming signal is not a pure sine; neither do i have a recipe for preparing the coefficient tables -- if we scale the individual coefficients by 1/sum their mix will not match what we want. I think we should probably abandon the cheby approach for now, this combined with the freqency dependency problem probably makes it a looser :( yep, it doesn't seem to be getting easier the more we look at it. the above approach could bring us close, but it does need xfading and two chebyshev shapers. We'd also need to split up the incoming signal by frequency though, and that would make it expensive to run. been thinking about how to do a hard clipper with sinc some more today, without real results though. Yeah, I think thats difficult, and probably not neccesary, the hard clip from a guitar amp doesn;t look very hard to me, so I recon you could just apply the shaper, plus a bit of oversampling, a LP filter and it'd be fine. Remind me: what was the thing that put us off chains of models? Was it just the messy bottom end? Or was there more? I'm pretty sure I can fix the muddly low harmonics and it sounds like other people aren't modeling the variation in harmonic amplitude with signal amplitude, so maybe it isn't important. - Steve
Re: [linux-audio-dev] ok, jump on slashdot right now, ALSA storyin progress
I wouldn't go as fas as to blame any developers for this. ALSA is being integrated in the mainline kernel and that by itself should keep everyone busy. I think its somehow the duty of the people who figured out how to configure it in an easy way to write it up (cfr. Patricks quicktoots section). I'm willing to do just that. The question is, what is the best place to write these things up ? Do I start to work on Debian specific documentation, or is it better to help on some general alsa documentation ? I think it would be best to have this info in the alsa-docs. Here's what I consider still needed to make the alsa-docs complete: - A paragraph on using alsaconf. - Anything that is distro specific. Although it might be better to make a page for this which people can add notes to. - Any info on using the controls for cards that have them. Specifically adat, wordclock, optical. I would like to have a section in the template for this but don't have any cards that use these so cannot test myself. -- Patrick Shirkey - Boost Hardware Ltd. For the discerning hardware connoisseur Http://www.boosthardware.com Http://www.djcj.org - The Linux Audio Users guide Um...symbol_get and symbol_put... They're kindof like does anyone remember like get_symbol and put_symbol I think we used to have... - Rusty Russell in his talk on the module subsystem
[linux-audio-dev] amp modelling
Steve wrote: Date: Sun, 3 Nov 2002 16:39:02 + From: Steve Harris [EMAIL PROTECTED] Yeah, I'm thinking we're not tackling it right, if behringer can knock out a virtual amp harware box for E150 it can't the that cycle hungry. There's a good chance I could get my hands on a Behringer V Amp 2 for as long as I need it. If I did, I'd be able to run whatever signal I liked through it and try different amp/speaker settings, different gain levels, etc. and produce a lot of data that would hopefully be of use in trying to produce some sort of amp modelling ladspa plugin. I'm open to suggestions as to what would be the most useful things to measure, and what to vary across measurements. My first thoughts were: - a range of pure tones, say starting at 440Hz and going up 3 octaves, - ~5 gain levels, - ~5 amp/speaker simulations, That'd give us 100 data points to work with when it comes to testing our models. Comments anybody? Stuart
Re: [linux-audio-dev] amp modelling
On Mon, Nov 04, 2002 at 02:19:51PM +1100, Stuart Allie wrote: My first thoughts were: - a range of pure tones, say starting at 440Hz and going up 3 octaves, low E on a bass is about 40 - 41 Hz, and on guitar it's about 81 Hz, so I'd suggest starting a lot lower than 440. -- Paul Winkler http://www.slinkp.com Welcome to Muppet Labs, where the future is made - today!
