Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

7501 discussions

by Sakari Bergen

On July 18, 2010 03:57:06 pm Ralf Mardorf wrote: > A lot of kids wish to have a kill switch for their guitars. > A kill switch is a short circuit, to 'stop' the audio signal. > > I'm not fine with this solution, but the kids argue, that e.g. an > interruption does cause unwanted noise, especially for over drive > sounds. IMO even using opto-electronics won't solve the issue, because > the noise of the transistor overdrive effect still would be hearable, > while for a short circuit there is silence. > > Has anybody an idea to solve this without a short circuit? > > I'm really not a fan of short circuits. Note, it's not possible to do an > interrupt all the times behind the latest noise generator and even an > interrupt could cause noise itself, while a short circuit indeed is a > good way to cancel sound. If you don't like short circuiting the mics, just switch the output jack hot lead between ground and the volume pot(s). Connecting the output to ground is the same as turning the volume down. There is no need to short the mics... On 19.07.2010 08:30, Tim E. Real wrote: > If you play a Gibson you can set the neck pickup volume to zero and > the bridge pickup volume to full and then toggle the pickup switch, > rapidly if desired, like Eddie van Halen on You Really Got Me. > Tim. Tom Morello gets real creative with his guirar, and uses this technique alot. He also unplugs his guitar to make the pedals and amps make noise (oscillate), and controls the noise with his wah pedal and by touching the tip of the plug to the guitar bridge (which is grounded). Good demonstration of how just cutting the signal lead can cause lots of noise, while a short will be more or less silent :) -Sakari-

14 years, 11 months

New modular synthesis library w/ ruby bindings

by Evan Buswell

Hi all, I've just released a beta of a modular synthesis library using Jack2, with a Ruby module. See http://ebuswell.github.com/Cshellsynth/ There's no mailing list for the project yet, but feel free to email me directly if you have questions/comments/concerns. Enjoy! Evan

14 years, 11 months

[Somewhat OT] Strange failure mode of a PC

by fons＠kokkinizita.net

Hello all, Early this week one of the three 'rendering' PCs of the WFS system in the Sala Bianca failed. It just appeared completely dead and didn't even try to boot when the power button was pressed, but the standby power (for the network interface) was available. I suspected the power supply, so ordered a new one which arrived two days ago. Installed it and things worked again. But now comes the interesting part. While installing the new PS, I also disconnected the wires to the power button, and to test I just used a screwdriver to short the two pins that normally connect to it. But when I reconnected the power button the PC switched off after a few seconds. So it seemed as if the power button was permanently being pressed. I again installed the old PS, and things worked as long as the power button was not connected. Measuring the power button switch with a multimeter showed an unstable resistance value of between 1 and 3k while it was not pressed. So I removed the thing, which turned out to be a cheap miniature switch, a little cube of around 8 mm size. I opened and disassembled it, and noticed that the contacts had some black dirt on them. Cleaned with aceton and reassembled, and things worked perfectly again. What I don't understand is how the contacts got so dirty. If a resistance of a few kOhm is enough to make it look as a closed contact then it can't be handling large currents, so there should not be any arcing. And the construction of the thing is such that it is virtually closed, no dust or whatever could ever creep in. Still it's quite sobering that this cheap 0.30 Euro thing was capable of bringing down a 1600 Euro workstation... Who would suspect a switch to fail in this way ? Ciao, -- Je veux que la mort me trouve plantant mes choux, mais nonchalant d’elle, et encore plus de mon jardin imparfait. (Michel de Montaigne)

14 years, 11 months

6 months job offer at Grame

by Orlarey Yann

The following job offer for a C++ developer may be of interest to you or some one you know. ==== About GRAME ==== Based in Lyon (France), GRAME, Centre National de Création Musicale (national center for musical creation) is a leading music institution dedicated to contemporary music and digital arts. Its activities range from artistic to scientific. GRAME's research department is involved in various French and European research projects as well as in several open source projects (Faust, Jackdmp, MidiShare, libMusicXML, GuidoLib, etc.) Grame's home page: http://www.grame.fr ==== Job Description ==== GRAME is looking for two C++ developers willing to collaborate together with its research team in the development of the future version of FAUST. FAUST (Functional Audio Stream) is a functional programming language specifically designed for high level real-time signal processing and synthesis. FAUST targets high-performance signal processing applications and audio plug-ins for a variety of platforms and standards. Its compiler translates Faust programs into equivalent C++ programs taking care of generating the most efficient code. Thanks to advanced compilation techniques, the resulting code can generally compete with, and sometimes even outperform, C++ code written by seasoned programmers. The future version of FAUST will introduce several new and exciting features, especially the support for multirate and multidimension processing. This will open a whole range of real time applications, from spectral to video processing. The recruited developers will be hired on a full-time limited-term contract of 6 months, from October 1st, 2010 to March 31, 2011. FAUST's home page: http://faust.grame.fr ==== Profile ==== * Excellent C++ programming skills : - methodical work, - clear programming and documentation style, - high productivity - good at understanding and modifying existing code * Strong Computer Science background : - compiler technologies - Lambda-calculus and functional programming - type systems and type inference, - code synthesis * Good Knowledge of audio/video processing techniques and associated Maths. * Familiarity with Linux and GNU Tools ==== How to apply ==== To apply, please send an email to orlarey at grame.fr mentioning "job offer at Grame" in the subject and adding : * A brief presentation letter stating your interest in the offer. * Your resume * Optionally, code samples and pointers to open source projects you have contributed to Yann Orlarey Scientific Director GRAME 9 rue du Garet BP 1185 69202 Lyon Cedex 01 France

14 years, 11 months

ALSA MIDI thru for live playing is ok (at least at the moment)

by Ralf Mardorf

Without running JACK and with running JACK -p2048 44.1Khz and 96KHz, without HR timer enabled and with HR timer enabled ALSA MIDI used to make a thru connection was always ok when playing live, not only for the PCI MIDI, but even for USB MIDI. When playing the recordings from my last test by Qtractor, there wasn't the issue anymore that FluidSynth and the internal Linux recorded FluidSynth sometimes were out of sync. The MIDI and the audio track were always in sync. I only tested it with system timer. Anyway, there definitive is jitter for the recorded FluidSynth. It's inaudible jitter, resp. it is audible when loop playing, because some beats are played to early, because of jitter with negative delay. So it's not an issue of bad timing, but because of notes that shouldn't be played, when loop playing. It's still a recording from the last test, not from today (note, I'm not writing about the hw MIDI at the moment). There must have been something bad, that is ok today. I wondered myself, because I never had this issues before. I didn't test MIDI jitter for hw MIDI today. Anyway, ALSA MIDI for MIDI thru is ok and also Qtractor always plays the MIDI and audio track in sync. For the important jitter tests I'll switch back to 64 Studio 3.0-beta3, there might be something broken for 64 Studio 3.3 alpha or it was just bad luck, anyway at least for FluidSynth with 3.0-beta3 there never were issues. Over the weekend I had no time to test MIDI as it was planned. It likely will be the same for the next days. Again there's hope that PCI MIDI jitter will be inaudible. Because even the USB MIDI was ok for live playing, I suspect that the jitter for the recordings is not regarding to ALSA MIDI. I wish I would have the time to do some recordings right now.

14 years, 11 months

Linux Plumbers Conference: Call For Papers

by rosea grammostola

Hi, AFAIK Lennart and some other Red Hat devs, where talking about the Linux Plumbers Conference at LAC2010, telling why it would be good if people from the linuxaudio world would join that conference and why it could improve the state of linuxaudio in the Linux environment. Here is a call for papers: http://www.linuxplumbersconf.org/2010/06/03/linux-plumbers-conference-call-… \r

14 years, 11 months

Midi tempo sync'd live drum machine

by Nathanael Anderson

Here is the setup i'm looking to do: midi master -> special program ddr pad -> special program special program -> hydrogen I've got a hardware midi device controlling the master tempo. aseqdump shows the tempo messages x times a second. I want to either find or make a program so I can use a ddr pad (usb gamepad) and assign different timed midi patterns to the buttons, so for example: if the program is configured for 4/4 time, when I hold down or toggle a button if note 36 is a bass drum and 41 is a snare then you'd have a basic drum and snare beat when both buttons are held down or toggled, of course i'd like to be able to have multiple patterns bound per button as well button one is set to play a quarter note midi note 36, then rest for the remaining 3 beats 1 - 36,quarter|rest,quarter|36,quarter|rest,quarter 2 - 41,eighth|rest,eighth|41,eighth|rest,eighth|41,eighth|rest,eighth|41,eighth|rest,eighth Each pattern would describe one measure, and the flow of a live solo performance could easily be changed on the fly, leaving hands free to play guitar. Anything out there like this, and I just don't know about it? If I don't find anything I want to hack something together, so a primer on midi tempo sync, and how to program with it would be appreciated. Thanks, Nathanael

14 years, 11 months

Re: [LAD] [PlanetCCRMA] FIxed alsa-tools' envy24control missing peak level meters and "Reset Peaks"

by Niels Mayer

On Fri, Jul 16, 2010 at 5:27 AM, Geoff King <gsking1(a)gmail.com> wrote: > Niels, Thank you for taking the time to work on improving Envy24Ctl. > I tried your patch for the peaks and it seemed to work fine for me. I > can't comment on the code (as I'm much more musician than programmer), > but had no problem patching and installing. Looking forward to trying > this new patch and whatever else you come up with. Geoff Geoff -- thank you for trying out the patch! (And, OT, thanks for working w/ Rui to help fix http://sourceforge.net/tracker/?func=detail&atid=733076&aid=3021645&group_i… :: "help fix qtractor crash on bus changing/configuration (3021645)" -- Envy24 and multichannel qtractor users, yes, it's time for a "svn up" ). FYI, to try out the new levelmeters "easy", if you're running Fedora x86_64, use the "envy24control" binary directly, or drop the levelmeters.c file into your build: http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.tgz ( for details http://nielsmayer.com/npm/Efficient-Meters-Envy24Control.README ) ........ On a completely different "note" the envy 24 manual ( http://alsa.cybermirror.org/manuals/icensemble/envy24.pdf ) has interesting info on the envy24 digital mixer that I've snapshotted: Diagram: http://nielsmayer.com/npm/envy24mixer-architecture.png Note the way it truncates in the mixer: the more inputs you "mix" at once, the fewer bits each input source gets, and it's not clear what kind of dither, or it's a straight truncate of 24... ultimately the envy24 seems oriented towards producing a 16 bit, and not 24 bit master (which makes sense given that the chip is well over a decade old and HD audio production for "prosumer" was rare): .......... 4.5.5 Multi-Track Digital Monitoring The Envy24 integrates a 36-bit resolution digital hardware mixer. The width of the data path is strictly to ensure that during processing of all the channels, under any condition, no resolution is lost. The dynamic range of the end user system will be limited by the range of the physical output devices used. In order to maintain identical gain to the input stream (i.e. 0dB), the resulting 24-bit is not msb-aligned to the 36-bit. The overflow bits correspond to the analog distortion due to saturation. The user would need to reduce the overall attenuation of the inputs to avoid clipping. Insertion of the digital mixer adds only a single sample cycle delay with respect to the original data. This extremely low latency all digital mixer provides monitoring functionality and can replace a traditional external analog input mixer. There are 20 independent audio data streams to mix and control the volume. ... .............. --Niels http://nielsmayer.com

14 years, 11 months

ALSA MIDI latency test results are far away from reality

by Ralf Mardorf

Hi :) my PCI MIDI devices passed the alsa-midi-latency-test always with < 1.01 ms, on several Linux, with several kernels and graphic drivers. It's audible that this can't be true. I was sceptic, when my USB MIDI passed with around 2 ms, because recordings did show that there is much more latency for the USB MIDI, when using Linux, just Windows is able to do such less jitter on my machine, see the archives. I won't install Windows again to compare the PCI MIDI. This computer can do better, but MIDI fails for Linux. This comparison is just for testing the abilities of the hardware. Please test yourself what I did today and you'll be able to here it too. It isn't just audible for gifted musicians, you'll really here that the FluidSynth DSSI Kick and the Kick played by an external MIDI drum module will be played one after another, but in unison. Note that I tested, that this drum module still is 100% ok. Please read the test and do the same as I did. I decided to do the audio MIDI jitter test with 64 Studio 3.3 alpha. I kept the proprietary 'nvidia' driver, even if the 'nv' driver, used by 64 Studio 3.0 beta, seems to cause x*10 µm less jitter. First I checked the package 'rt-irq'. It's version 20090810-0ubuntu1 (karmic) and regarding to diff, I didn't over installed the current version before. On Rui's download page http://www.rncbc.org/jack/ the current version is 20090920. I installed a dummy package rtirq-init_20090920_all.deb and updated both rtirq files. For /etc/default/rtirq I edited line 30 from RTIRQ_NAME_LIST="rtc snd usb i8042" to RTIRQ_NAME_LIST="rtc snd i8042" line 33 from RTIRQ_PRIO_HIGH=90 to RTIRQ_PRIO_HIGH=98 I fixed the MIDI adaptor cable by screws to the 16:0 device and used the audio IOs of the same card. It's the card with IRQ 20. Envy24 Control automatically chose this card. After shutdown and startup I did perform the ALSA MIDI latency test. $ su -c "poff dsl-provider" $ su -c "cpufreq-selector -g performance" ^C $ cd /etc/init.d $ ./rtirq status PID CLS RTPRIO NI PRI %CPU STAT COMMAND 386 FF 95 - 135 0.0 S< irq/8-rtc0 1140 FF 90 - 130 0.0 S< irq/21-ICE1712 1137 FF 89 - 129 0.0 S< irq/20-ICE1712 379 FF 85 - 125 0.0 S< irq/1-i8042 378 FF 84 - 124 0.1 S< irq/12-i8042 102 FF 50 - 90 0.0 S< irq/9-acpi 565 FF 50 - 90 0.0 S< irq/14-ide0 570 FF 50 - 90 0.0 S< irq/16-ohci_hcd 587 FF 50 - 90 0.0 S< irq/22-ahci 597 FF 50 - 90 0.0 S< irq/19-ehci_hcd 598 FF 50 - 90 0.0 S< irq/22-ohci1394 601 FF 50 - 90 0.0 S< irq/17-ohci_hcd 603 FF 50 - 90 0.0 S< irq/18-ohci_hcd 606 FF 50 - 90 0.0 S< irq/17-ohci_hcd 609 FF 50 - 90 0.0 S< irq/18-ohci_hcd 932 FF 50 - 90 0.0 S< irq/7-parport0 1634 FF 50 - 90 0.3 S< irq/18-nvidia 1946 FF 50 - 90 0.0 S< irq/26-eth0 4 FF 49 - 89 0.0 S< sirq-high/0 5 FF 49 - 89 0.0 S< sirq-timer/0 6 FF 49 - 89 0.0 S< sirq-net-tx/0 7 FF 49 - 89 0.0 S< sirq-net-rx/0 8 FF 49 - 89 0.0 S< sirq-block/0 9 FF 49 - 89 0.0 S< sirq-tasklet/0 10 FF 49 - 89 0.0 S< sirq-sched/0 11 FF 49 - 89 0.0 S< sirq-hrtimer/0 12 FF 49 - 89 0.0 S< sirq-rcu/0 18 FF 49 - 89 0.0 S< sirq-high/1 19 FF 49 - 89 0.0 S< sirq-timer/1 20 FF 49 - 89 0.0 S< sirq-net-tx/1 21 FF 49 - 89 0.0 S< sirq-net-rx/1 22 FF 49 - 89 0.0 S< sirq-block/1 23 FF 49 - 89 0.3 S< sirq-tasklet/1 24 FF 49 - 89 0.0 S< sirq-sched/1 25 FF 49 - 89 0.0 S< sirq-hrtimer/1 26 FF 49 - 89 0.0 S< sirq-rcu/1 $ su -c "chgrp audio /dev/hpet" $ su -c "sysctl -w dev.hpet.max-user-freq=64" $ su -c "modprobe snd-hrtimer" $ alsa-midi-latency-test -l Port Client name Port name 14:0 Midi Through Midi Through Port-0 16:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI 20:0 TerraTec EWX24/96 TerraTec EWX24/96 MIDI $ alsa-midi-latency-test -Rrw=5 -i16:0 -o16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s sample; latency_ms; latency_ms_worst 0; 1.07; 1.07 9999; 1.00; 1.07 > latency distribution: 1.0 - 1.1 ms: 9994 ################################################## 1.1 - 1.2 ms: 6 # > SUCCESS best latency was 0.99 ms worst latency was 1.07 ms, which is great. $ alsa-midi-latency-test -Rrw=5 -i16:0 -o16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s sample; latency_ms; latency_ms_worst 0; 1.06; 1.06 timeout: there seems to be no connection between ports 16:0 and 16:0 I didn't check any connections, but run the test again. I've got no idea what's wrong, when I get those timeouts. The adaptor cable with opto-coupler is a brand new non self made one and the timeout can happen for both cards, my old card S/N 00xxxxx with an Envy24 chip not by Terratec and the new second hand card from Ebay S/N 04xxxxx with an Envy24 chip by Terratec. I didn't compare all the other chips, but the board's layouts don't differ. When doing the audio MIDI test the MIDInterface did work without missing data. $ alsa-midi-latency-test -Rrw=5 -i16:0 -o16:0 > alsa-midi-latency-test 0.0.3 > set_realtime_priority(SCHED_FIFO, 99).. done. > clock resolution: 0.000000001 s sample; latency_ms; latency_ms_worst 0; 1.06; 1.06 5727; 1.06; 1.06 9999; 1.01; 1.06 > latency distribution: 1.0 - 1.1 ms: 9992 ################################################## 1.1 - 1.2 ms: 8 # > SUCCESS best latency was 0.99 ms worst latency was 1.06 ms, which is great. Compared to the test done with the old setup http://lists.64studio.com/pipermail/64studio-users/2010-July/004537.html nothing did change. $ jackd -Rch -dalsa -dhw:0 -r96000 -p1024 -n2 jackdmp 1.9.5 no message buffer overruns no message buffer overruns JACK server starting in realtime mode with priority 10 creating alsa driver ... hw:0|hw:0|1024|2|96000|0|0|nomon|swmeter|-| 32bit Using ALSA driver ICE1712 running on card 0 - TerraTec EWX24/96 at 0xcf00, irq 20 configuring for 96000Hz, period = 1024 frames (10.7 ms), buffer = 2 periods ALSA: final selected sample format for capture: 32bit integer little-endian ALSA: use 2 periods for capture ALSA: final selected sample format for playback: 32bit integer little-endian ALSA: use 2 periods for playback $ qtractor Version: 0.4.6 Build: Jun 3 2010 15:26:56 JACK Session support disabled. A Yamaha DX7 was directly connected to hw MIDI in and an Alesis D4 was directly connected to hw MIDI out. The analog audio IOs from the sound card and the main outs from the Alesis D4 were connected to a Behringer UB2442FX-Pro. So, valid home recording equipment, without any critical stuff. Excepted to the limit for the sound quality, there shouldn't be any issues caused by this setup. For the MIDI audio test's LXDE session I'm running GNOME terminal tab 1 JACK2, tab 2 Qtractor. Evolution offline + this Email opened for writing to the lists. Envy24 Control and nothing else. For Qtractor I switched from queue timer (resolution) 'system timer (1000 Hz)' to 'HR timer (1000000000 Hz)' and restarted Qtractor. 1. I disconnected all audio connections for JACK and connected hw MIDI in to hw MIDI out. Live I played forefinger left hand kick, thumb left hand snare and forefinger right hand ride. To get an impression for the latency I connected the DX7 MIDI out directly to the D4 MIDI in and then I reconnected to the PCI card. The difference is alarming :(. Yamaha DX7 --> Alesis D4 results in a 100% musical groove. Yamaha DX7 --> PC --> Alesis D4 results in extreme latency, it's hardly possible to keep on grooving. This never ever is a latency of just 1 ms, I'm sure the ALSA MIDI latency test is mistaken. Even a MIDI thru chain by several MIDI devices won't cause such bad latency. 2. I disconnected all ALSA MIDI connections. I disconnected the DX7 from the hw interface. Qtractor was connected to hw MIDI out, while hw MIDI out still was connected to the D4. 3. After adding a MIDI track I added a MIDI clip (from bar 2 to bar 4, 4/4, 120BPM) with those notes: Time_____Note_____V._Duration 2.01.000 (36) C 1 64 0.00.240 2.02.000 (37) C#1 64 0.00.240 2.02.480 (36) C 1 64 0.00.240 2.03.480 (37) C#1 64 0.00.240 2.04.000 (36) C 1 64 0.00.240 2.04.480 (37) C#1 64 0.00.240 2.04.720 (36) C 1 64 0.00.240 3.01.000 (36) C 1 64 0.00.240 3.01.480 (37) C#1 64 0.00.240 3.02.480 (36) C 1 64 0.00.240 3.03.240 (36) C 1 64 0.00.240 3.03.480 (37) C#1 64 0.00.240 3.04.000 (36) C 1 64 0.00.240 3.04.480 (37) C#1 64 0.00.240 Loop play for hw MIDI by Qtractor is a disaster, hence I copied and paste repeated it 39 times, pasted with the grid set to beat. The 'rhythm' then was from bar 2 to bar 82. 4. After adding a second MIDI track, I copied all clips from the first to the new track. The second track isn't for hw MIDI, but FluidSynth DSSI. I connected Qtractor audio out to system playback. Before I could play with the hw MIDI track muted, Qtractor crashed. I opened a third tab for the GNOME terminal and tried to kill Qtractor without success. $ su # pidof qtractor 4173 # kill 4173 # killall qtractor # killall -9 -w qtractor ^C # killall -9 qtractor I stopped JACK. [...] JackAudioDriver::ProcessAsync Process error JackEngine::XRun: client = Qtractor was not run: state = 1 JackAudioDriver::ProcessAsync Process error JackEngine::XRun: client = Qtractor was not run: state = 1 JackAudioDriver::ProcessAsync Process error JackEngine::XRun: client = Qtractor was not run: state = 1 JackAudioDriver::ProcessAsync Process error JackEngine::XRun: client = Qtractor was not run: state = 1 JackAudioDriver::ProcessAsync Process error JackAudioDriver::ProcessAsync Process error ^Cjack main caught signal 2 Unknown error... FATAL: exception not rethrown Aborted But ... # killall -9 qtractor didn't work. FWIW the Alesis D4 was set up to NOTE: 036 C1 Kik/43: Slammin' PITCH: +1.00 VOL: 99 PAN: <> OUTPUT: MAIN MODE: MULTI NOTE: 037 C#1 Snr/92: Big Stik PITCH: +1.00 VOL: 85 PAN: <> OUTPUT: MAIN MODE: MULTI CHANNEL: 01 As usual for 64 Studio 3.3 alpha several restarts resulted with issues. I had to turn the computer off and on. 1. Started GNOME terminal tab 1. su -c "poff dsl-provider" 2. Started Evolution in offline mode and opened this Email. 3. GNOME terminal tab 1 $ su -c "cpufreq-selector -g performance" Password: ^Cspinymouse@64studio:~su -c "chgrp audio /dev/hpet" I wonder why Ctrl + C is needed after running cpufreq-selector. For Lucid it's the same. $ su -c "sysctl -w dev.hpet.max-user-freq=64" $ su -c "modprobe snd-hrtimer" $ jackd -Rch -dalsa -dhw:0 -r96000 -p1024 -n2 4. Opened a second tab for GNOME terminal. $ qtractor /mnt/music/all-in-one_supplier/PCI_MIDI_test.qtr HR timer still is selected. The hw MIDI track is muted. The FluidSynth DSSI MIDI track is ready to play. FluidSynth is using 808Set.sf2. Qtractor audio out was connected to system playback and system capture was auto-connected to Qtractor audio in. I now disabled auto connect, but kept this audio connections, resp. I had to manually restore them, perhaps disabling auto connect, did disconnect them. I had to disconnect and manually restore Qtractor MIDI out, because it didn't connect to the 16:0 EWX 24/96 as stored, but to the 20:0 EWX 24/96. 5. I launched Envy24 Control. 6. I pushed play for Qtractor transport. I stopped it. Set up gain for FluidSynth from the default -14 dB to 0 dB. Played again. Unmuted the hw MIDI track. The notes played by the soundfont and by the D4 are fluctuating between completely being out of sync and between being played unison. I stopped playing. RESULT THE PCI MIDI INTERFACE WITH AN ALSA-MIDI-TEST-LATENCY RESULT OF < 1.1 ms IS COMPLETELY USELESS TO MAKE MUSIC, BUT 'GREAT'. AND IT'S AUDIBLE THAT THERE IS MUCH MORE JITTER BUT 1.1 ms. Any hints how to solve this are welcome. What information is needed? Cheers! Ralf

14 years, 11 months

The linux audio servers are down :(

by Ralf Mardorf

Shit, I tried to do some research, but lad.linuxaudio.org and linuxav.org/mailarchive seem to be down :( and it seems that my last mail didn't come through the list :(. Has anybody else this trouble? If not please send me an email. Shit! Ralf

14 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Linux-audio-dev