Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

4 participants
7502 discussions

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, 8 months

[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, 8 months

[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, 8 months

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, 8 months

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, 8 months

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

by Chris Cannam

Clemens: > Most sound cards don't have an internal timer that could be used for > MIDI timing. ALSA uses whatever timer is configured, the default for > this is the RTC timer. It is? For ALSA sequencer queues? I thought the default was system timer. Maybe it just depends on the modules you have loaded. My impression from Rosegarden users' reports has been that trying to use the ALSA sequencer with the RTC timer (something I've never bothered with myself: I always use a 1000Hz system timer) is a reliable way to lock up your system completely, with most kernels from about 2.6.13 or so onwards. I've been meaning to investigate with the latest ALSA source and at least make a decent bug report for ages, but you know the way it is, there are only sixty hours in the day. It would be wonderful if some excellent person had fixed it in the meantime. Chris

18 years, 8 months

[linux-audio-dev] USB keyboard on Linux

by Carlo Trimarchi

Hi, I'm new here. I'd like to buy a USB Keyboard and I was thinking to a M-AUDIO Keystation 49E. http://www.m-audio.com/products/en_us/Keystation49e-main.html Do you know if it is compatible with linux? Have you ever tried it? Thanks, bye.

18 years, 8 months

[linux-audio-dev] MIDI is playing but no sound

by Mulyadi Santosa

Hello everybody Perhaps not directly related with audio development, but I will be glad if someone can help me. I downloaded a free MIDI file from Internet (drum sample MIDI from "MIDI" wikipedia entry) and I tried to play it on my FC5. I am using both aplaymidi and KMid, but no sound comes out. Other than this silence, everything else seems OK i.e no error such as corrupted file. I tested the same file with WIndows Media Player and it plays fine. What was I doing wrong here? Here is the specification: Chip : Realtek ALC 650 ALSA: alsa-lib-devel-1.0.11-3.rc2.2, alsa-utils-1.0.11-3.rc2, alsa-lib-1.0.11-3.rc2.2 Kernel version: 2.6.16-1.2074_FC5 Desktop environment: KDE 3.5.1 Motherboard and chipset : MSI KT4V using VIA KT 400 Thanks in advance for the help. regards, Mulyadi

18 years, 8 months

[linux-audio-dev] best option for audiovisual synchrony

by Simon Barthelmé

Hi all, We're in the process of porting an open source Matlab toolbox to Linux called the Psychtoolbox. It's a piece of software that's widely used within neuroscience and psychophysics, to display graphics and play sounds in experiments. It uses OpenGl for its graphics backend, and right now the sound support is just matlab's, which is really poor. A lot of us researchers are interested in audiovisual experiments, where we study how the brain combines auditory and visual information (for example in speech perception). Concretely speaking, that means we need to get as precise a timing and synchrony as we can possibly get. A typical experiment will go something like this : - display a flash and, at the same time, play a beep - wait for response The tricky bit is of course getting a flash that's totally synchronous with the beep. Absolute synchrony is not achievable without dedicated hardware, but we need to get an approximation that's within the few ms range. From what I've read it seems that Linux is a pretty good platform for that, since it has low latency/real time support. What I need to know is how I should go about implementing some kind of FlashAndBeep function, that guarantees that the sound starts playing as soon as the display buffer is flipped, with the shortest predictable delay possible. Is ALSA the way to go ? JACK maybe ? Anything else ? I'd love to read about any piece of advice you might have. Do ask me if you need more details. Thanks a lot, Simon Barthelmé PhD Student Laboratoire de Psychologie de la Perception CNRS/Université Paris V lpp.psycho.univ-paris5.fr

18 years, 8 months

[linux-audio-dev] jack_mixer - frist release

by Nedko Arnaudov

jack_mixer is GTK (2.x) JACK audio mixer with look similar to it`s hardware counterparts. It has lot of useful features, apart from being able to mix multiple JACK audio streams. Homepage with screenshots: http://home.gna.org/jackmixer/ Download: http://download.gna.org/jackmixer/ -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

18 years, 8 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