Linux-audio-dev

linux-audio-dev@lists.linuxaudio.org

3 participants
7448 discussions

by Aurélien Leblond

Hi, I have been debugging an issue in Giada where sometimes it would get disconnected from Jack1 at start (not Jack2). During my debugging, I found that the JackSyncCallback method setup in Giada's jack_set_sync_callback uses Fl::lock which blocks the main process and Jack doesn't like that. I believe that's what the problem is (especially as after removing them I cannot reproduce it anymore)... Does anyone who knows Jack much better than I do (in fact I'm a real noob in that area) think I'm right in my investigation's finding? Thanks in advance, Aurélien

9 years, 5 months

lac2015 photo gallery & videos

by Rui Nuno Capela

hi all, every year the post-lac nostalgic syndrome gets its toll... all the photos taken by this lousy photo-shooter of yours during the lac2015@jgu-mainz are now online: http://www.rncbc.org/lac2015 the even lousier videos taken from some of the linux sound night live acts are also delivered unedited and online: http://www.youtube.com/user/rncbchannel enjoy -- rncbc aka. Rui Nuno Capela

9 years, 5 months

ambix vs JUCE, segfault

by Fernando Lopez-Lezcano

Anyone out there using ambix on Linux? I'm seeing various instabilities, for example trying out the converter standalone I get a segfault when connecting output ports, and it looks like the Jack JUCE component is doing some unaligned memory copies. Any hint on how to fix this? I get Ardour crashes if I try to use the converter LV2 plugin as well. See below for a trace of the standalone binary... Thanks for any help! -- Fernando #0 0x00007ffff507bdd6 in __memcpy_avx_unaligned () from /lib64/libc.so.6 #1 0x000000000069f6d1 in juce::FloatVectorOperations::copy(float*, float const*, int) () #2 0x000000000069ec87 in juce::AudioSampleBuffer::copyFrom(int, int, juce::AudioSampleBuffer const&, int, int, int) () #3 0x0000000000685452 in Ambix_converterAudioProcessor::processBlock(juce::AudioSampleBuffer&, juce::MidiBuffer&) () #4 0x00000000006e0e7d in juce::AudioProcessorPlayer::audioDeviceIOCallback(float const**, int, float**, int, int) () #5 0x000000000068e0b7 in juce::AudioDeviceManager::audioDeviceIOCallbackInt(float const**, int, float**, int, int) () #6 0x000000000069a694 in juce::JackAudioIODevice::processCallback(unsigned int, void*) () #7 0x00007ffff148c2fc in Jack::JackClient::CallProcessCallback() () from /lib64/libjack.so.0 #8 0x00007ffff148c204 in Jack::JackClient::ExecuteThread() () from /lib64/libjack.so.0 #9 0x00007ffff1489c0b in Jack::JackClient::Execute() () from /lib64/libjack.so.0 #10 0x00007ffff14aa2fc in Jack::JackPosixThread::ThreadHandler(void*) () from /lib64/libjack.so.0 #11 0x00007ffff5d3052a in start_thread () from /lib64/libpthread.so.0 #12 0x00007ffff503622d in clone () from /lib64/libc.so.6

9 years, 5 months

Job opportunity at CCRMA

by Fernando Lopez-Lezcano

Hi all, Ever dream of maintaining GNU/Linux servers and providing support for a closely knit community of users interested in everything related to sound, music and DSP? Designing high performance GNU/Linux-based workstations that are completely silent? Packaging your favorite free software so that users worldwide can easily download and install it? Designing, maintaining, managing and deploying complex multichannel studio and concert diffusion systems? Working with a community of interdisciplinary students, researchers and faculty from all over the world? Doing some music and research on the side? (and more, of course). And all that at CCRMA, the Center for Computer Research in Music and Acoustics in the middle of Silicon Valley? And working with Nando?[*] (well, nothing's perfect :-) Details are here: https://stanfordcareers.stanford.edu/job-search?jobId=66452 Just in case you don't know, the Stanford Center for Computer Research in Music and Acoustics (CCRMA) is a multi-disciplinary facility where composers and researchers work together using computer-based technology both as an artistic medium and as a research tool. https://ccrma.stanford.edu/about Waiting for applications... -- Fernando [*] https://ccrma.stanford.edu/~nando/

9 years, 6 months

OpenAV ArtyFX 1.3 Call for testing

by Harry van Haaren

Hi All, As OpenAV it is my pleasure to call for testing of ArtyFX 1.3. The code is available online right now! [1] New plugins include: - Driva (Guitar Distortion) - Whaaa (Wah pedal) Credits: - Whaaa DSP from WAH Plugins by Fons - Driva distortion algorithms ported from Rakarack project OpenAV may still change parameters based on feedback - note this is a call for testing. But its sounding pretty awesome already here ;) Stay tuned for an official release announcement after the LAC[2], and tune in to the OpenAV AVTK + other important OpenAV news.. Cheers! -Harry [1] https://github.com/harryhaaren/openAV-ArtyFX [2] lac.linuxaudio.org/2015/ [3] http://lac.linuxaudio.org/2015/speakers?uid=22 -- http://www.openavproductions.com

9 years, 6 months

Advanced Gtk+ Sequencer aka GSequencer now on GitHub

by Joël Krähemann

Hi all, me just migrated gsequencer to GitHub. http://www.gsequencer.org Further me did renamed binary from `ags` to `gsequencer`. About the state of the sequencer: Version 0.4.2-44 is believed to be stable. Since me don't have the time to test it well, me need people to test it. Please, let me know your experiences. MIDI support is intended to be added for release Version 0.4.3 and many other new exciting features. If someone can help with ALSA rawmidi, please let me know. I don't want to do JACK, since it is believed to be somehow the Qt thing. What me can say so far about MIDI me read years ago about it in "The computer music tutorial - The MIT Press, ISBN 0-262-68082-3". And MIDI consist of messages which are routeable. Someone giving specification how the MIDI message struct is passed to ALSA and how it looks like would be great. Thank you in advance Joël

9 years, 6 months

Re: [LAD] [alsa-devel] Fw: Using loopback card to Connect GSM two way call to the real sound card UDA1345TS

by Clemens Ladisch

Srinivasan S wrote: > I didn't understand what is 'two channel devices' does The two channels are "left" and "right". > Regarding bindings as you explained"bindings.x y" or "bindings { x y }" maps channel x of this device to > channel y of the slave device. > > I didn't understand channel x of this device means is it the real sound card??? which is the current device ie., channel x of this device means??? > > I didn't understand channel y of the slave device means??.. ie., which is slave device here???? "This device" is the virtual device that is defined. The slave device is the device whose name is specified with "slave.pcm". Regards, Clemens

9 years, 6 months

Re: [LAD] [alsa-devel] Fw: Using loopback card to Connect GSM two way call to the real sound card UDA1345TS

by Clemens Ladisch

Srinivasan S wrote: > CPU consumption is 18%, with above asound.conf & the app > alsa_loopback_min_mono.c for establishing my GSM two way call (ie., > VINR to VOUTR & VINL to VOUTL) , this is very huge & I want to reduce > this CPU consumption drastically, Is there any other ways in alsa where > I can do this two way GSM call (ie., VINR to VOUTR & VINL to VOUTL) > without using alsa_loopback_min_mono.c application dmix needs more CPU than dshare because it needs to mix multiple streams together; if possible, use dshare instead of dmix. dshare needs more CPU than direct access to the device because the data needs to be copied and reformatted. dshare is needed only when the application(s) cannot handle the format of the actual device; if possible, change your application to handle the two-channel devices. > And am hearing echo, when I do GSM calls when using the above attachd > asound.conf & the app alsa_loopback_min_mono.c, could you please help > me out is there any options to do echo cancellation in alsa? ALSA has not built-in echo cancellation. You have to implement this yourself, or use some third-party library. If dmix/dshare alone eats 18 % CPU, it is unlikely that this is feasible without hardware support. > Am trying to completely understand the above attched asound.conf, but > am not still very clear w.r.t the understanding of bindings "bindings.x y" or "bindings { x y }" maps channel x of this device to channel y of the slave device. Regards, Clemens

9 years, 6 months

Re: [LAD] Call for testing: new ALSA driver for Digi 002/003 family

by Takashi Sakamoto

Hi Damien, On Apr 02 2015 09:28, Damien Zammit wrote: > On 02/04/15 09:41, Takashi Sakamoto wrote: >> Several issues are still remained: >> * When allocates 2 or more channel numbers for the device, after 15 to >> 20 seconds from playbacking, any PCM samples causes noisy sound. Then, >> all of LED on the front panel light. The streaming still continues >> correctly. > I have not seen this behaviour with your latest driver, Takashi. > I think you would see this if the midi quadlet is confused with the pcm > quadlets and you feed audio data into the midi port. (I have seen this > before) The channel is *not* PCM or MIDI, it's IEEE 1394 isochronous resource channels. I shouhd have mention about it, sorry. In short, when two or more devices are connected on the same IEEE 1394 bus, the driver may cause the issue (or not). >> * The actual effects of external clock source is not clear. When set >> the clock source is somewhat external, even if stopping the clock >> source, the device continues to sound PCM samples against my expectation. > > I have successfully tested the device with ADAT and SPDIF sync. When I > connect external clock source to the SPDIF-in port and send > 0xffffe0000118 1 the SPDIF led light turns on and the streaming now > syncs to the new clock. A flashing Sync led means that the sample rates > are mismatched and the sync is not working correctly. But sync works > well when sample rates are matched. OK. My Digi 002 Rack has no LEDs to show current clock source, so I have no way to check the actual sync in my eyes. I request you to test stopping the supply of clock source during streaming. I expect the streaming is stopped suddenly, then PCM playback/capturing also stop. > I tried 0x011c but I am not convinced that this is related to ADAT at > all. I think it is a switch to select the mode of SPDIF between > consumer and pro SPDIF modes? I am guessing here but SPDIF sync no > longer works when I toggle the mode to 1, and it has no effect when I > attach ADAT cable and sync to ADAT, then toggling the mode does nothing. In my Digi 002 Rack, it's a selector between S/PDIF or ADAT for optical input/output interfaces. If not in your Digi 003+, this seems to be model-dependent issue and I'll drop it from the driver (digi00x-proc.c). Regards Takashi Sakamoto

9 years, 6 months

Re: [LAD] Call for testing: new ALSA driver for Digi 002/003 family

by Damien Zammit

On 02/04/15 11:28, Damien Zammit wrote: > On 02/04/15 09:41, Takashi Sakamoto wrote: >> Several issues are still remained: >> * When allocates 2 or more channel numbers for the device, after 15 to >> 20 seconds from playbacking, any PCM samples causes noisy sound. Then, >> all of LED on the front panel light. The streaming still continues >> correctly. > I have not seen this behaviour with your latest driver, Takashi. > I think you would see this if the midi quadlet is confused with the pcm > quadlets and you feed audio data into the midi port. (I have seen this > before) > >> * The actual effects of external clock source is not clear. When set >> the clock source is somewhat external, even if stopping the clock >> source, the device continues to sound PCM samples against my expectation. > I have successfully tested the device with ADAT and SPDIF sync. When I > connect external clock source to the SPDIF-in port and send > 0xffffe0000118 1 the SPDIF led light turns on and the streaming now > syncs to the new clock. A flashing Sync led means that the sample rates > are mismatched and the sync is not working correctly. But sync works > well when sample rates are matched. > > I tried 0x011c but I am not convinced that this is related to ADAT at > all. I think it is a switch to select the mode of SPDIF between > consumer and pro SPDIF modes? I am guessing here but SPDIF sync no > longer works when I toggle the mode to 1, and it has no effect when I > attach ADAT cable and sync to ADAT, then toggling the mode does nothing. > > Damien >

9 years, 6 months

Jump to page:

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