Linux-audio-dev August 2013

linux-audio-dev@lists.linuxaudio.org

20 participants
21 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

Screencasting with JACK [SOLVED!]

by J. Liles

As some of you may recall, every time I've posted a demo video to LAD, I've had to include a disclaimer excusing the poor quality due to a lack of functional screencasting tools. Well, it took a couple of weeks of hair pulling and many, many hours of testing, but I finally arrived at a solution. Anyone who wants to create a screencast and record audio via JACK *in perfect sync* must do the following: Get ffmpeg. Apply this patch to it: https://github.com/original-male/FFmpeg/commit/d02509d04d396a98646ca81e9ba3… Build it with vorbis and h264 support. Then, start your favorite desktop environment. I use Xephyr for this. Have jack running (at -r 48000) Then run the following command: ffmpeg -fflags +genpts+igndts -f x11grab -vsync 0 -r 30 -s 1920x1080 -i :${DISPLAY}.+0,0 -vcodec h264 -f jack -ac 2 -r:a 48000 -i screencast -acodec pcm_s16le -r:v 30 -vsync 2 -async 1 -map 0:0,1,0 -map 1:0 -preset ultrafast -qp 0 "$FILE" Where DISPLAY is the number of your X11 display and FILE is the filename for the screencast. I use a .mkv extension for the matroska container. Remember to connect the streams you want recorded to the 'screencast' JACK inputs! With this setup I'm able to record a full 30 FPS @ 1080P with audio in perfect sync. Please share your results too. With some more evidence I might have a good case to get ffmpeg to accept my patch. Enjoy!

10 years, 2 months

Jack midi sequencer, threading and shared state

by Burkhard Ritter

Hi all, I just joined the developers list as I've been looking into adding Jack midi support to one of my favourite sequencers (harmonySEQ) and need some advice related to threading and shared data. I know these issues have come up before, specifically I found two related threads [1][2], but I am still confused as to what would be the best approach. (I am also new to thread programming in general.) As this is a sequencer the main data structure is a list of patterns where each pattern contains a list of notes. Patterns can be manipulated while being played back. Both the GUI thread and Jack thread should be able to modify the patterns, e.g. a midi event might toggle a pattern on/off, the GUI can insert a note into a pattern, or add or remove a pattern. I've considered different approaches (separate data for each thread, various versions of shared data), but I believe all of them make at least two assumptions: That reading and writing byte-sized data (e.g. a bool flag) and that updating pointers is atomic. I got a bit confused reading this thread [2]. Are these assumptions correct? To be more specific, one of the schemes I came up with followed the idea of using only one shared data structure which has to be in a consistent state at all points in time. To ensure this I would have to be very careful as to how I update the data structure. For example, if the GUI added or removed a note from a pattern (which might involve a memory reallocation) it would do so by performing theses changes on a copy of the current pattern and then replace the original pattern by updating the pointer to this new version of the pattern. Simple updates (e.g. turning a pattern on / off) would be performed directly on the pattern as I consider them atomic. To keep references to patterns throughout the code I would use some global registry, as I cannot use pointers for they "expire" (might point to an old version of the pattern). Does that make sense? Are there some obvious flaws with that scheme that I oversaw, are there better ways to go about it? I am really quite new to this kind of programming issues, I would appreciate any pointers and advice! Thanks, Burkhard [1] http://linux-audio.4202.n7.nabble.com/Best-practice-for-sharing-complex-dat… [2] http://linux-audio.4202.n7.nabble.com/Atomic-Operations-td58961.html

10 years, 2 months

Re: [LAD] Weird USB MIDI sysex problem

by Clemens Ladisch

Gordon JC Pearce wrote: > On Sat, Aug 31, 2013 at 07:04:31PM +0200, Clemens Ladisch wrote: >>> not to send that too soon otherwise the CZ will misbehave in various >>> interesting ways. Once all the patch data is send - with breaks for >>> acks in between - the final 0xf7 is sent to terminate the sysex dump. >> >> So the messages used by the CZ1000 in this protocol are not actually >> MIDI messages. > > In what way are they not MIDI messages? All the messages in the CZ1000 protocol (header, acks, final F7) together make up just a single MIDI message; the individual messages, taken separately, are not valid MIDI messages. >>> According to the USB MIDI spec there is an event packet to send just >>> single bytes. >> >> There are devices that do not support this single-byte packet. > > That would be most devices. > >>> This isn't implemented in the kernel, >> >> It's used for real-time messages. > > No, that's CIN 0x5 which only passes a single byte if its upper bit is set. CIN 0x5 is used only for system common messages, not for system real- time messages. >>> With a bit of testing, I've determined that at least the USB >>> interfaces I have at hand do not support sysex. They will pass some >>> interestingly "interpreted" version of sysex, which is of course >>> corrupted and unreadable by the device. >> >> In what way corrupted? > > It doesn't send complete messages. The USB MIDI spec does not work on the raw byte level (except when using CIN 0xf) but on the level of complete MIDI messages. (Running status isn't used either.) > This is an inherent flaw in the USB MIDI spec. Apparently Roland, who wrote the spec, did not think that anybody would do anything particularly weird. Regards, Clemens

10 years, 3 months

Re: [LAD] Weird USB MIDI sysex problem

by Clemens Ladisch

Gordon JC Pearce wrote: > On Sat, Aug 31, 2013 at 11:34:33AM +0200, Clemens Ladisch wrote: >> Gordon JC Pearce wrote: >>> The only exception is if I send something not a multiple of three >>> bytes but terminate the transfer with 0xf7, it will send >>> everything including the 0xf7 - but this kills the sysex transfer. >> >> _Every_ SysEx message must be terminated with F7. > > The CZ1000 expects seven bytes to start the sysex transfer, at which > point it will reply with a message and wait for an acknowledge. The > the PC should start to send the patch data, but it's quite important > not to send that too soon otherwise the CZ will misbehave in various > interesting ways. Once all the patch data is send - with breaks for > acks in between - the final 0xf7 is sent to terminate the sysex dump. So the messages used by the CZ1000 in this protocol are not actually MIDI messages. >>> Is it really impossible to just send raw bytes over a USB MIDI cable? >> >> It is possible to send MIDI messages over a USB MIDI cable. > > According to the USB MIDI spec there is an event packet to send just > single bytes. There are devices that do not support this single-byte packet. > This isn't implemented in the kernel, It's used for real-time messages. > it would be incredibly handy for sysex transfers, debugging and the > like. > > Perhaps the answer is just to ditch alsa and poke the USB device with > libusb? Or change the driver to always use single-byte packets (modify the first "if" in snd_usbmidi_transmit_byte). > With a bit of testing, I've determined that at least the USB > interfaces I have at hand do not support sysex. They will pass some > interestingly "interpreted" version of sysex, which is of course > corrupted and unreadable by the device. In what way corrupted? Regards, Clemens

10 years, 3 months

Weird USB MIDI sysex problem

by Gordon JC Pearce

Hi folks, I'm having some really odd behaviour trying to send sysex to a synth where I can only send (using snd_rawmidi_write) in three-byte blocks. The only exception is if I send something not a multiple of three bytes but terminate the transfer with 0xf7, it will send everything including the 0xf7 - but this kills the sysex transfer. The synth I'm trying to send MIDI to - a Casio CZ1000 - expects seven bytes of data to start a patch dump, at which point it will send a handshake back to the computer. Now if I pad the output with zeros the synth *will* handshake, but then not respond to the handshake acknowledge presumably because of the extraneous zeros. I can't figure out what I'm doing wrong with this. Example code here: http://dpaste.com/1361268/ This is tested with the MIDI out of my Emu 1x1 cable plugged into the MIDI in of a sound module and MIDI in on the interface plugged into the MIDI through on the module - so there is no "processing" of the MIDI messages. Is it really impossible to just send raw bytes over a USB MIDI cable? -- Gordonjcp MM0YEQ

10 years, 3 months

Re: [LAD] Weird USB MIDI sysex problem

by Ralf Mardorf

http://www.kasploosh.com/projects/CZ/how_to/amidi-cz101-receive.html :D I missed this, since I googeld for the list ponly, so using amidi it's possible to write a synth editor by shell script, at least sending some commands is possible without having the knowledge how to program in a Linux common high language such as C.

10 years, 3 months

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