Linux-audio-dev October 2006

linux-audio-dev@lists.linuxaudio.org

50 participants
31 discussions

[linux-audio-dev] LAC-Konzertreport auf SWR2 15.5. 23h (German only)

by Michael Iber

Hi lists, my little report on the lac-concerts and some other subjects of the lac in Karlsruhe will be broadcasted tomorrow on SWR2 JetztMusik Magazin at 23h. Michael

17 years, 7 months

[linux-audio-dev] Re: [linux-audio-user] Recording ADAT inputs on RME hammerfall 9636/52

by Stephen Cameron

Well, mixed results tonight. I was able to get some sound to go across the ADAT cables from the PC to the AW4416. But not good sound. On the bright side, I think I more or less understand connecting things up with jack, ecasound, and so on. On the bad side, so far it's not working too well. I monitored things with "jackmeter" and this meter registered peaks near 0dB for the stuff I was playing with ecasound, and pretty high levels for the most part. On the AW4416, the levels were registering between -30dB and -48dB. I guess I don't understand how ADAT works. I was under the impression the signal going across the cables was digital -- and so to get a reduction in levels like that, I would expect some digital numbers would have to go from being big numbers to being small numbers, which seems unlikely thing to happen to numbers encoded as pulses going down a cable. So I conclude I don't know how ADAT works, except it's not as I imagined it did. Oh, and besides a drastic loss of signal level, the signal was distorted strangely. Hard to describe. This may be due to xruns... I haven't got things to work without xruns yet, but that shouldn't cause a drop in levels, right? Just kind of choppiness, dropouts, crappy sound, right? Transfering from the AW4416 to the PC did not work at all. on capture_1 and capture_2, I got very low level white noise apparently. Are those the s/pdif ports? On the other channels input was dead silence. I tried both ADAT ports on the RME board, with similar results on each. I tried swapping the two ADAT cables in case one of the cables was bad... this did not seem to make a difference. Maybe the RME just transmits harder than the Yamaha, so it's signal makes it across (just barely, crossing the finish line at -48dB) while the yamaha's signal dies. I did change the RME's frequency to 44.1kHz in qjackctl's setup window. Maybe there are some clues in here: [root@zuul R15]# cat /proc/asound/R15/rme9652 RME Digi9636 (Rev 1.5) (Card #2) Buffers: capture f6a00000 playback f6400000 IRQ: 10 Registers bus: 0xea000000 VM: 0xf88a2000 Control register: 48029 Latency: 1024 samples (2 periods of 4096 bytes) Hardware pointer (frames): 1024 Passthru: no Clock mode: autosync Pref. sync source: ADAT1 ADAT1 Input source: ADAT1 optical IEC958 input: Internal IEC958 output: Coaxial only IEC958 quality: Consumer IEC958 emphasis: off IEC958 Dolby: off IEC958 sample rate: error flag set ADAT Sample rate: 44100Hz ADAT1: No Lock ADAT2: Sync ADAT3: No Lock Timecode signal: no Punch Status: 1: off 2: off 3: off 4: off 5: off 6: off 7: off 8: off 9: off 10: off 11: off 12: off 13: off 14: off 15: off 16: off 17: off 18: off __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

17 years, 11 months

[linux-audio-dev] Multiplexing 4 channels on SPDIF

by Fons Adriaensen

Hello all, Core Sound <http://www.core-sound.com/default.php> willsoon be offering a tetrahedral (Ambisonic) microphone at a very reasonable price. They are also working on a combined preamp + AD converter unit for this mic. This will be able to multiplex the 4 channels over a single SPDIF link, by using it a the double sample frequency. I'm currently working on a software controller unit for this microphone. It will perform A-format to B-format conversion, and allow measured impulse responses to be used for calibrating the four mics. The result should be a very high quality portable surround recording system at a reasonable price (compared to other solutions which cost easily five times as much). The remaining problem is the demultiplexing of the two double speed SPDIF channels to four channels. It could either be done within the ALSA layer, or in JACK's ALSA backend. Doing this in a JACK client will not work unless it would be the only client - all others would get the wrong idea of the sample frequency and buffer size. So here's my question to both the ALSA and JACK teams: what would be your idea of a solution for this ? -- FA Lascia la spina, cogli la rosa.

18 years

[linux-audio-dev] [ANN] Vmwaredspjack 1.3, Snd-ls 0.9.7.6 and Jack_capture V0.3.8

by Kjetil S. Matheussen

Vmwaredspjack ============= This is the vmwaredsp program, made by Petr Vandrovec, which makes vmware work with esd or arts. This version adds jack support as well. (Unfortunately, jacklaunch (which is a similar program) doesn't work with vmware, but I think Gunter is working on it... :-) .) The program isn't always working that well, but if used with care (don't trust the output too much) and proper tuning, you can use professional windows audio software in vmware using jack for audio communication. Download from http://www.notam02.no/arkiv/src/ Snd-ls v0.9.7.6 =============== Snd-ls is a distribution of Bill Schottstaedt's sound editor SND. Its target is people that don't know scheme very well, and don't want to spend too much time configuring Snd. It can also serve as a quick introduction to Snd and how it can be set up. Changes 0.9.7.1 -> 0.9.7.6: --------------------------- -Proper debug output in case startup fails. -Fixed bug in jack audio. -Temporary remove the fft menu because its not working with the 26.9.2006 version of Snd. Bug found by Dragan Noveski. -Check for the existence of the sndfile.h header file before compiling. If it doesn't exist, snd-ls will refuse to run. Problem reported by Krzusztof Gawlas. -Make sure snd starts up even if no file was loaded during startup. Bug found by Dragan Noveski. -Really apply the workaround for the menu problem. Download from http://www.notam02.no/arkiv/src/snd/ Jack_capture V0.3.8 =================== jack_capture is a small program to capture whatever sound is going out to your speakers into a file. This is the program I always wanted to have for jack, but no one made. So here it is. Changes 0.3.7 -> 0.3.8: ----------------------- *Added the --recording-time option to stop recording after a certain number of seconds. *Quitting with CTRL-C/SIGINT writes remaining buffer to disk before ending program. Download from http://www.notam02.no/arkiv/src/

18 years

[linux-audio-dev] Linuxaudio.org -- call for new member projects

by Ivica Ico Bukvic

Apologies for cross-posting. Please forward the announcement to your respective lists (if applicable). Yes, it's that time of the year. In our continued bi-monthly track of membership drives, I would like to extend an open invitation to all Linux audio projects who are not already a member of the consortium to consider joining and therefore help us continue our efforts at consolidation of Linux audio resources. The membership is free and the consortium's structure allows members to gauge their level of involvement and subsequently the time overhead it bears. In the recent months there have been a number of exciting new projects introduced to the Linux audio scene. This is very encouraging as it suggests not only continued, but also growing vitality of our platform of choice. Linuxaudio.org's mission is to help maintain this vitality by offering various programs to its membership base as well as the entire Linux audio community. Perhaps one of the most important programs is our mission to consolidate Linux audio resources and by doing so foster collaboration as well as connections with the commercial industry and outside investors. For this reason, I sincerely hope that you will consider joining the consortium. For more info on the membership, benefits, etc. please visit linuxaudio.org. We have our next new member announcement set for this coming Thursday November 2nd. Should you happen to have any additional questions and/or concerns, please do not hesitate to contact me. Best wishes, Ivica Ico Bukvic, D.M.A. Linuxaudio.org Director Virginia Tech Department of Music - 0240 Blacksburg, VA 24061 (540) 231-1137 (540) 231-5034 (fax) ico(a)linuxaudio.org http://www.music.vt.edu/people/faculty/bukvic

18 years

Re: [linux-audio-dev] about MIDI timing...

by Chris Cannam

Me: > I'm not aware of anyone these days successfully > using Rosegarden with snd-rtctimer - if anyone out > there is, do say so. To test: * start RG (version 1.0 or newer) * go to Settings -> Configure Rosegarden -> Sequencer -> Synchronisation * change the sequencer timing source option to RTC * close configuration window, press play. It probably doesn't matter whether you have a file loaded or not. Success -> play pointer moves smoothly Failure -> system locks up solid, reboot required. If it does lock up, you may need to edit your rosegardenrc to restore the timer setting before you can run RG again. Chris

18 years

[linux-audio-dev] [ANN] FreeBoB 1.0 released - Firewire Audio for Linux

by Pieter Palmers

Greetings, Now that JACK 0.102.20 and QJackCtl 0.2.21 being released, the FreeBoB team is proud to present libfreebob 1.0. The FreeBoB project aims to provide a generic solution for using Firewire (semi-)pro-audio devices in Linux. This release provides support for the devices based on the BridgeCo DM1000 or DM1500 chipset that are running the BeBoB firmware. For a list of supported devices, consult our website at freebob.sf.net. FreeBoB currently provides an interface library that allows firewire audio devices to be used with the JACK audio server, using a dedicated backend. This backend is included in the official JACK releases, from this version on (i.e. 0.102.20). The latest version of QJackCtl also includes support for this FreeBoB backend. MIDI support is provided through ALSA sequencer. Feature list: * Automatic detection & configuration of devices. If there are multiple devices attached to the same firewire bus, freebob merges them into one big device. The devices have to be synced externally (wordclock/spdif) so that they don't drift. Note that this release cannot setup the boxes to be synced yet, being synced is a precondition at the moment. (I tested this with 2 phase88's connected with wordclock, and this works without the need for any special setting because the Phase88 automatically chooses wordclock slave when there is a wordclock signal present. This can be different for other models). * Audio I/O on all analog channels at all sample rates supported by the device. SPDIF/ADAT I/O works in most cases (when presented as analog IO by the device). AC3 passthrough doesn't work. * Midi I/O for all midi ports the device implements, using alsa-sequencer * Round-trip latency figures around 5ms (depends on system configuration). 10ms is achievable on all well-configured machines Not supported yet: * Hardware mixing ("zero latency" mixer) * Device-specific configuration (input gain switches, sync source selection, midi control mappings, ...) * ALSA for audio IO * Special SPDIF/ADAT stream support You can download FreeBoB 1.0 at our sourceforge page: http://sourceforge.net/project/showfiles.php?group_id=117802 more info at freebob.sf.net What's next? We are working on the second generation of the FreeBoB codebase. The 1.0 release is the endpoint for the codebase that dates back to the start of the project. The 2.0 codebase is a complete redesign of the system using 1.0 as a 'golden spec'. While the 1.0 version is BeBoB-only, the 2.0 codebase is designed as a framework to support all firewire based audio boxes. The current level of functionality is almost the same for both codebases. The main difference is that 1.0 had one year of testing and 2.0 doesn't, it's still in the alpha stage. Needless to say that 2.0 will outperform 1.0 by far ;). Of course this redesign isn't for the sake of aesthetic beauty or lack of things to do... I can announce that we are already working on broadening the supported device list. Currently there is support for the Motu Traveller and the Motu 828 (through reverse engineering). There are also contacts with the DICE-II developers to implement generic support for devices based upon their chipset. As an extra, support for Metric Halo devices is also in the pipeline. Once all of these devices are supported, we will cover a very large part of the Firewire audio device spectrum. The most important void will be RME Fireface support, and for the real budget users: Behringer and Hercules devices. That's all folks! Pieter Palmers (on behalf of the FreeBoB team)

18 years

[linux-audio-dev] about MIDI timing...

by Mulyadi Santosa

Hello list... I am curious to research further about MIDI timing and here is something I want to ask... I wonder, if we missed the (MIDI?) event a bit (perhaps 1 miliseconds?), what would happen? I guess it will be underrun? Or technically, do we determine a playback as "choppy" by calculating the time difference between sending two successive MIDI events? I don't know much about this issue, so I will gladly receive any thoughts. On the other hand, last night I observed how timidity++ works by using strace and I found no *sleep() (nanosleep, msleep and friends). Does it mean, major MIDI software synthesizers use non system sleep mechanism for the timing? I also read that not all Linux kernel sound card driver enable the internal card timer, thus the software must rely on system timer. Is it correct? thanks in advance for your help and attention. regards, Mulyadi

18 years

Re: [linux-audio-dev] about MIDI timing...

by Chris Cannam

Me: > No, it genuinely went from working to broken And actually, I think my recollection is wrong. I think it probably broke in 2.6.8-rt, and in mainline in either 2.6.9 or 2.6.10. Before that it worked fine, but we always used the system timer instead for RG because it seemed simpler (it was always 1000Hz then) and we stuck with that as the default and I guess rather abandoned the RTC option. Sorry for being so lax. If it does work now, then of course, that's great. Chris

18 years

Re: [linux-audio-dev] about MIDI timing...

by Chris Cannam

Lee: > This is/was a bug or multiple bugs in the kernel's RTC driver. It > started to appear around 2.6.13 because that was the kernel release > where they regressed the default timer granularity from 1ms to 2.5ms, > forcing apps like Rosegarden to switch to RTC based timing. No, it genuinely went from working to broken - it's not a case of always being broken but never previously being necessary. It broke first in RT kernels, so I'm guessing it broke in mainline with an RT patch merge. I'm not aware of anyone these days successfully using Rosegarden with snd-rtctimer - if anyone out there is, do say so. Either you get a 1000Hz kernel or you suffer with crap timing. Clemens: > Kernels >= 2.6.15 work. The most recent such report we had was from a user of OpenSUSE 10.1 (with 2.6.16 I think?). I suggested trying an ALSA driver upgrade; apparently it didn't help. The thread should be easily found in the Rosegarden list archives by searching for rtc and opensuse. I don't have a computer here to test it on at all myself at the moment, I'm afraid. I will do later. Honest. Chris

18 years

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 October 2006