Linux-audio-dev November 2013

linux-audio-dev@lists.linuxaudio.org

26 participants
19 discussions

by Frank Kober

Hi, QMidiArp 0.5.2 has just seen the light of the day. It brings mainly two improvements. One is a comeback, that of tempo changes on the fly, and that now includes also tempo changes of a potential Jack Transport master. Also the Jack Transport starting position is finally taken into account, so that QMidiArp should be in sync also when starting the transport master not at zero. The second one is Non Session Manager support, mainly thanks to the work done by Roy Vegard Ovesen! Note that for compiling in NSM support you will now need liblo as dependency. Enjoy, and enjoy LAC in Graz this year Frank ________________________________ QMidiArp is an advanced MIDI arpeggiator, programmable step sequencer and LFO. Everything is on http://qmidiarp.sourceforge.net qmidiarp-0.5.2 (2013-05-09) New Features o Tempo changes are again possible while running, both manually or by a Jack Transport Master o Jack Transport position is now taken into account when starting, QMidiArp used to start always at zero o Muting and sequencer parameter changes can be deferred to pattern end using a new toolbutton o Modules in the Global Storage window have mute/defer buttons o Global Storage location switches can be set to affect only the pattern o Non Session Manager support with "switch" capability (thanks to Roy Vegard Ovesen) General Changes o NSM support requires liblo development headers (liblo-dev package)

9 years, 2 months

OpenAV Productions : Sorcer

by Harry van Haaren

Hey Everybody, I'm happy to announce OpenAV productions: http://openavproductions.com OpenAV productions is a label under which I intend to release my linux-audio software projects. The focus of the software is on the workflow of creating live-electronic music and video. The release system for OpenAV productions is one based on donations and time, details are available on http://openavproductions.com/support Sorcer is a wavetable synth, and is ready for release. Check out the interface and demo reel on http://openavproductions.com/sorcer Greetings from the LAC, -Harry

9 years, 7 months

itop

by elboulangero

Hello everyone, lately I had to fight big XRUN troubles, and thanks to this forum I finally solved that. This excellent thread saved me: http://linuxaudio.org/mailarchive/lau/2012/9/5/192706 On my long quest, I tried to see a little bit more what happened with the IRQs on my system. I searched for a kind of 'top' utility to monitor the interrupts, but the only apps I found were either deprecated, or missed some cool features. So, I ended up writing my own tool to monitor the file /proc/interrupts. It's available a this address: https://gitorious.org/elboulangero/itop As its name indicates, it behaves pretty much like top, but for interrupts. It's quite a simple thing, that I tried to enhance a bit with some cool features: + refresh period can be specified. + two display modes: display interrupts for every CPU, or only a sum of all CPU. + display every interrupt (sorted like /proc/interrupts), or only active interrupts (sorted by activity). + in case the number of interrupts changes during the execution of itop (due to a rmmod/modprobe), it's handled without any fuss. + command-line options are also available as hotkeys for convenience. + at last, the program display a summary on exit. The idea is that this summary could be copied/pasted in emails to help debugging. If anyone is interested, feel free to try and comment ! Cheers

9 years, 7 months

Support for Steinberg UR22 (Yamaha USB chipset 0499:1509)?

by cullinan＠rocketmail.com

Hi, there! I just got a Steinberg UR22 USB<->Audio / MIDI interface for my semi-prof. DJ work. I am working on Linux (only), but wanted to give this new product a chance. Well, it's basically a nice device but with an Yamaha chipset in it which seem unfortunately not supported from the latest (3.7.9) linux kernel(s). My questions are: - How likely is it to get this device fully supported on linux? - What needs to be done to get this device fully supported? I am an electrical engineer and did some linux device driver development in the past on some DMA stuff, but I am quite new to linux audio. But I am willing to help somewhere... I could try to reverse-engineer the USB stuff on Windows with the usbmon/usbsnoop/libusb things... But if it's too much work, to get it working, I could also just decide to send it back to Steinberg and thank them for not supporting Linux with their products. The USB information I could get is: $ aplay -l doesn't list that device $ lsusb ... Bus 002 Device 016: ID 0499:1509 Yamaha Corp. ... (See the more comprehensive $ lsusb -v below...) Related USB devices are: 0499:1501 Yamaha 0499:1507 Yamaha THR10 0499:1509 Yamaha Steinberg UR22 (what I am talking about) 0499:150c Yamaha THR10C Related search resuls are: Getting a Steinberg CI1 USB audio interface to work http://ubuntuforums.org/showthread.php?t=1696336 Yamaha THR10 amp / USB2.0 audio interface http://linux-audio.4202.n7.nabble.com/Yamaha-THR10-amp-USB2-0-audio-interfa… Thank you, Clemens (different one as in last link) -----8<----- $ lsusb -v -d 0499:1509 Bus 002 Device 014: ID 0499:1509 Yamaha Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0499 Yamaha Corp. idProduct 0x1509 bcdDevice 1.00 iManufacturer 1 Yamaha Corporation iProduct 2 Steinberg UR22 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 442 bNumInterfaces 5 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 0a 24 01 00 01 34 00 02 01 02 ** UNRECOGNIZED: 0c 24 02 01 01 01 00 02 03 00 00 00 ** UNRECOGNIZED: 09 24 03 02 01 03 00 01 00 ** UNRECOGNIZED: 0c 24 02 03 03 06 00 02 03 00 00 00 ** UNRECOGNIZED: 09 24 03 04 01 01 00 03 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 44 ac 00 80 bb 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x002a 1x 42 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 88 58 01 00 77 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x004e 1x 78 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 10 b1 02 00 ee 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x07 EP 7 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0096 1x 150 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 04 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 44 ac 00 80 bb 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x002a 1x 42 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 2 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 04 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 88 58 01 00 77 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x004e 1x 78 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 3 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 07 24 01 04 01 01 00 ** UNRECOGNIZED: 0e 24 02 01 02 03 18 02 10 b1 02 00 ee 02 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0096 1x 150 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 255 iInterface 0 ** UNRECOGNIZED: 07 24 01 00 01 24 00 ** UNRECOGNIZED: 06 24 02 02 01 00 ** UNRECOGNIZED: 09 24 03 02 01 01 01 01 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x01 EP 1 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x82 EP 2 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 4 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 255 Vendor Specific Protocol iInterface 0 ** UNRECOGNIZED: 07 24 01 00 01 24 00 ** UNRECOGNIZED: 06 24 02 02 01 00 ** UNRECOGNIZED: 09 24 03 02 01 01 01 01 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) -----8<-----

9 years, 7 months

Re: [LAD] Community Interaction and Working Together

by michel dominique

On ven. 20/09/13 13:11 , Harry van Haaren <harryhaaren(a)gmail.com> wrote: > Hello all Users & Devs of linux-audio-land, > > Moving forward from the topic on Aeolus and forking projects, perhaps it is > wise to look at how the community as a whole can grow from this situation: > > 1) It seems the frustration of forks is mainly due to lack of > communication. > 2) Had appropriate communication been in place, patches could have been > merged. > 3) If 1) and 2), then the community flourishes as a whole. > > In the Aeolus thread on LAD, Michel Dominique wrote (and I feel its > relevant here): > "That imply we must communicate more with each other" > "I think this is a big problem, and not only related to Fons work, or the > LAD, but to the whole community." One think I have done is to add in the About box a few buttons to launch things like the mail list subscription page, mailto and irc. The function look for $BROWSER, if it doesn't exist, the user get the opportunity to set it, and the browser will do the rest. It is too early now for me to know if it make a big difference. This will not replace an email list, but can be a good complement, and make life easier for someone that want to get in touch with the development, or have an issue, a comment or whatever to ask or report. And well, this is oriented first to users. Developers must be able to find my email on the website or the source code... > > The mailing list you're reading from now is one of the central hubs for the > community: > The -developers list is the perfect place to announce projects, forks, > patches etc. +1 > The -users list is good for asking users and interested parties questions. +1 Dominique > > I will try to announce more patches / code, to contribute upstream, and > hopefully benefit the community. > Cheers, -Harry > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/listinfo/linux-audio-dev [1] > > > > Links: > ------ > [1] > http://awebmail.vtx.ch/parse.php?redirect=http://lists.linuxaudio.org/listi > nfo/linux-audio-dev >

9 years, 11 months

liblo release candidate, call for testing

by Stephen Sinclair

Hello audio developers, I have just updated a new release candidate for LibLo 0.28rc. Due to a couple of bad bugs slipping into the last release I have decided to take a more precautionary approach this time and ask for public testing of this release candidate before a final 0.28 release. That is to say, this release fixes several important issues from 0.27, but is not intended for use in production until after this round of testing. To download liblo-0.28rc: https://sourceforge.net/projects/liblo/files/liblo/0.28rc/liblo-0.28rc.tar.… For more information, the liblo project page can be found at: http://liblo.sourceforge.net/ ----------- 2013-11-24: Release candidate 0.28rc This is a release candidate 0.28rc of LibLo, the lightweight, easy to use implementation of the Open Sound Control protocol. Open Sound Control (OSC) is a protocol for communication among computers, sound synthesizers, and other multimedia devices that is designed for use over modern network transports. This is mainly a bugfix release due to some deal breakers that unfortunately made it through to the 0.27 release. Additionally, this is the first release to include a modern C++11 object-oriented wrapper for the LibLo API. Please test! Important bug fixes: * Fixed checking of vararg markers on 64-bit systems * Fixed hang in TCP blocking test * Several potential bugs prevented through static analysis Additional changes: * Add function lo_bundle_get_timestamp() * Add C++11 wrapper, `lo_cpp.h', and test program * Support for a few more build tools: clang/clang++, ccache thank you, Steve

9 years, 12 months

Re: [LAD] Headless RME HDSP/HDSPM mixer settings

by raf

hello, tested successfully with a HDSP 9652. great usefull tool ! notice that if hdspmixer has not been started after bootup (means the card is not initialized in some way), hdspdump throw no error, and creates a dump file filled with 0. It means that alsa is not throwing errors either as your programs goes nicely to the end. I've been looking at hdspmixer code for some days now to make it console only, removing FLTK dependencies. Your program gives me motivation to go on with this hard task. Raphaël Le 26 nov. 2013 à 19:32, linux-audio-dev-request(a)lists.linuxaudio.org a écrit : > Re: Headless RME HDSP/HDSPM mixer settings

10 years

A question about audio file interfaces

by Fons Adriaensen

These questions are really directed to Paul Davis (as the main Ardour dev), Erik de Castro Lopo (libsndfile author), and anyone with experience in this field. Imagine a real-time audio processing app reading (or writing) lots of audio files, possibly evaluating a complex timeline consisting of many separte pieces. To make things work some (or a lot of) buffering and lookahead will be necessary. There are at least three distinct places where this can be done: 1. the file system(s) and kernel 2. any library used to acess audio files, 3. the application itself. Of these, only (1) will be aware of any hardware related issues, and only (3) will be aware of what is expected to happen in the (near) future. (2) sits somewhere between the two. In view of this, what is currently the best way for an app to read/write audio files, the basic read() and write() calls, or the stdio interface ? More specifically, if one would write a library to access a particular audio file format (not supported, or only partially by e.g. libsndfile), how 'smart' in terms of buffering, lookahead etc. should that library be, or not try to be, in order to perform well with apps like e.g. Ardour ? What form would the preferred API take ? Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow)

10 years

QMidiArp 0.5.3 maintenance release

by Frank Kober

Dear all, QMidiArp 0.5.3 fixes a number of bugs and should from now on replace 0.5.2. It also has some minor functional improvements, all is listed below. With thanks to all reporters, contributors and translators. And....enjoy! Frank ------------------------------------ QMidiArp is an advanced MIDI arpeggiator, programmable step sequencer and LFO for Linux with ALSA and JACK MIDI backends. ------------------------------------ Downloads are available at http://qmidiarp.sourceforge.net/ direct link: http://sourceforge.net/projects/qmidiarp/files/qmidiarp/0.5.3/qmidiarp-0.5.… ------------------------------------ qmidiarp-0.5.3 (2013-11-26) New Features o Random functions for sequencer and LFO steps and arp repeat mode (feature request #5 Keith Milner) Improvements o NSM support now handles import/export/clear to facilitate getting started (Roy Vegard Ovesen) o Tempo is now MIDI-controllable (MIDI-learn) o Sequencer transpose slider is now MIDI controllable (MIDI-learn) (feature request #7) o Sequencer pattern maximum length extended to 32 bars (feature request #6) Fixed Bugs o LFO offset jumped back to fixed value when MIDI controlled (bug #6 distrozapper) o Arp trigger behavior was not practical with chords pressed on keyboard (bug #7 Burkhard Ritter) o JACK Transport no longer worked when no JT Master tempo was present (bug #5 Barney Holmes) o Deleting an arp pattern in text window while running caused crash o Note lengths were not consistent between alsa and jack backends o Note lengths did not account for current tempo o Sequencer did not honor "D" button when MIDI controlled o Seq note length is now a 16th at half slider scale

10 years

Headless RME HDSP/HDSPM mixer settings

by Adrian Knoth

Hi! I wrote a quick&dirty cmdline tool to dump and restore the internal mixer state of an RME card (no matter if handled by snd_hdsp or snd_hdspm, so this should apply to almost all RME cards except the new MADIFX). I call it hdspdump for now, if you like, grab it here: http://adi.loris.tv/hdspdump.c Almost no sanity checks, it's proof of concept atm. For your convenience, I'll also attach it to this mail (who knows what will happen to the URL above in the future...) Idea is as follows: 1. Run hdspmixer ONCE to make your desired mix. 2. Run hdspdump hw:DSP > dumpfile to dump the current mixer state. 3. Run hdspdump hw:DSP write < dumpfile to restore the mixer state. Of course, you can have multiple files for different mixes. It's most likely used for headless setups with static signal routing. I have only tested it on my Multiface, so if you have other RME gear and have a few minutes to waste, I'm happy to hear from you. Cheers /* compile with gcc -std=gnu99 -o hdspdump hdspdump.c -lasound */ #include <stdio.h> #include <stdlib.h> #include <alsa/asoundlib.h> void usage(char *name) { fprintf(stderr, "usage: %s cardname [write]\n", name); fprintf(stderr, "Example: %s hw:DSP > dumpfile\n", name); fprintf(stderr, "Example: %s hw:DSP write < dumpfile\n", name); } void error_and_out(int err) { fprintf(stderr, "ALSA error: %s\n", snd_strerror(err)); exit(err); } int main(int argc, char **argv) { int err; char *cardname; snd_hwdep_info_t *info; snd_hwdep_info_alloca(&info); snd_ctl_elem_id_t *id; snd_ctl_elem_value_t *ctl; snd_ctl_t *handle; int write = 0; if (argc < 2) { usage(argv[0]); exit(1); } cardname = argv[1]; if (argc > 2 && (0 == strcmp("write", argv[2]))) { write = 1; } snd_ctl_elem_value_alloca(&ctl); snd_ctl_elem_id_alloca(&id); snd_ctl_elem_id_set_name(id, "Mixer"); snd_ctl_elem_id_set_interface(id, SND_CTL_ELEM_IFACE_HWDEP); snd_ctl_elem_id_set_device(id, 0); snd_ctl_elem_id_set_index(id, 0); snd_ctl_elem_value_set_id(ctl, id); if ((err = snd_ctl_open(&handle, cardname, SND_CTL_NONBLOCK)) < 0) { error_and_out(err); } for (int source = 0; source < 128; source++) { for (int dest = 0; dest < 64; dest++) { snd_ctl_elem_value_set_integer(ctl, 0, source); snd_ctl_elem_value_set_integer(ctl, 1, dest); if (write) { char buf[1024]; fgets(buf, sizeof(buf), stdin); snd_ctl_elem_value_set_integer(ctl, 2, atoi(buf)); if ((err = snd_ctl_elem_write(handle, ctl)) < 0) { snd_ctl_close(handle); error_and_out(err); } } else { if ((err = snd_ctl_elem_read(handle, ctl)) < 0) { snd_ctl_close(handle); error_and_out(err); } printf("%li\n", snd_ctl_elem_value_get_integer(ctl, 2)); } } } snd_ctl_close(handle); }

10 years

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 November 2013