All ladspavst users/contributors,
A ladspavst visitor has brought to my attention that the ladspavst.linuxaudio.org has been spammed for quite some time, rendering a page into useless goop of spam. This is mainly due to lack of moderation. As a result, I've no other choice than to take the site offline until further notice. If you or someone you know is supposed to take care of this site, please contact me and we'll figure out the best way to bring this site back online. Until that happens, the site will remain offline.
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
Hi,
I'm wondering what the size limit is for SysEx messages in the JACK MIDI
and ALSA sequencer APIs. My observations so far:
In JACK MIDI, a SysEx message can be as large as the MIDI port buffer,
which in turn has the same size as an audio buffer for one period. This
is assuming that there are no other events transmitted on the same port
during the same period.
Is this correct? Or are applications somehow expected to handle larger
SysEx messages split over multiple periods?
In the documentation of the ALSA sequencer API, I couldn't find any
mention of an upper limit. Some sources suggest that ALSA splits SysEx
messages into chunks of 256 bytes, but from my own attempts at sending
larger messages, it seems the limit is actually somewhere around 5500
bytes. Unfortunately ALSA doesn't seem to report an error when I try to
send larger chunks, instead the messages just disappear. Can anyone shed
some light on how to handle larger SysEx messages correctly?
Thanks,
Dominic
Hi all,
Yesterday I released version 1.0.21 of libsndfile. Its available here:
http://www.mega-nerd.com/libsndfile/#Download
Main changes for this version are:
* Add a couple of new binary programs to programs/ dir.
* Remove sndfile-jackplay (now in sndfile-tools package).
* Add windows only function sf_wchar_open().
* Bunch of minor bug fixes.
Cheers,
Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/
Hi.
I just happened to stumble about a (what I call) pretty subtle
bug in typical ALSA PCM code:
root@fzidpc73:/tmp# cat test.c
#include <stdio.h>
int main() {
int period = 1024;
int nperiods = 3;
int rate = 96000;
unsigned buffer_time = 1000000*period*nperiods/rate;
printf("%d\n", buffer_time);
}
root@fzidpc73:/tmp# ./test
-12739
root@fzidpc73:/tmp# sed -i -e 's/int rate/unsigned int rate/' test.c
root@fzidpc73:/tmp# gcc -o test test.c
root@fzidpc73:/tmp# ./test
32000
I.e., don't trust this boilerplate formula blindly.
--
CYa,
⡍⠁⠗⠊⠕
Dear fellow FOSS enthusiasts,
Last week's L2Ork debut was a great success with the performance hall packed and people standing in the back. We've had a tremendous amount of positive feedback and it has been truly hart-touching to learn that people genuinely cared about and were moved by what we had to share. As some of you may be already aware, our story also made the Slashdot and our server has received close to a half a million hits since its posting. Likewise, we've been featured on regional TV channels as well as various international news outlets.
As our thanks to all who have so generously supported us both in person and through the endless corners of the internet, we've posted a track from our weekend recording session. "Citadel" is a piece for soprano and L2Ork that uses a poem by Ivan Gundulic, a famous Croatian poet from the Baroque era. The piece was recorded in a beautifully reverberant Burruss rotunda on the Virginia Tech campus. No post-processing has been applied to the recording beyond a minor eq to soften lows.
To listen please visit http://l2ork.music.vt.edu/main/ and click on the Media->Jukebox, or simply click on the link in what is currently the top post on the L2Ork blog.
Once again, thank you all for your kind support. We will be starting a public l2ork-dev list soon, so if you wish to contribute, participate, or start your own L2Ork, please do not hesitate to join in on the discussion. Likewise, should you feel compelled to leave a comment, please feel free to do so on our jukebox page (no registration required).
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Assistant Co-Director, CCTAD
CHCI, CS, and Art (by courtesy)
Virginia Tech
Dept. of Music - 0240
Blacksburg, VA 24061
(540) 231-6139
(540) 231-5034 (fax)
ico(a)vt.edu
http://www.music.vt.edu/faculty/bukvic/
Thanks for pointing that out to me.
I've started a version which uses atomic pointer exchange,
and this is something I wasn't aware of.
I think it shouldn't be a problem right now, as I keep
the objects I use in memory, and I don't need the reaction
of the program to the pointer swap to be a realtime operation.
thanks again for your reply,
lieven
On 11/29/2009 03:36 PM, Ken Restivo wrote:
> On Tue, Nov 24, 2009 at 10:33:45AM +0100, Karl Hammar wrote:
>
>> Nick Copeland:
>>
>>> Adrian Knoth:
>>>
>>>> I'm also somewhat interested in the network part, I feel IPv6 could help
>>>> a lot. It supports autoconfiguration and it has decent multicast
>>>> support, so it would be possible to broadcast/multicast the streams on
>>>> the net (LAN). This could be useful if you want to access the stream at
>>>> a mixing console for a life setup and simultaneously record it on a
>>>> computer.
>>>>
>>> Put another way, it would be far more compatible if this were done over
>>> an IP stream rather than any native ethernet stream, not least it could use
>>> any ethernet driver that linux supports rather than a small subset of them.
>>>
>> Ack, a standard ip-stream is a sensible first choise.
>>
>>
>>> Perhaps the project needs to be specified with regards to its goals?
>>>
>> ...
>>
>> My goals is "just" to extend another project (industrial i/o).
>> What would your goals be ?
>>
>> Shall we decide on a single mailing list ?
>>
>>
> IIRC the motivation for this was:
>
> 1) Firewire is going away on laptops
> 2) USB 2.0 is proprietary and non-standard
> 3) Because of (1) and (2), Linux Audio users will soon be left without any way to do multichannel recording on laptops.
>
> The original thread converged on a goal pretty quickly: an inexpensive, multi-channel audio interface which is open hardware and software, and uses Gig Ethernet as its physical connection method.
>
> So, if I were going to put the goal simply: I'd like a Focusrite Saffire (or equivalent) that runs over Ethernet, please :-) Price-wise, it'd be nice if it cost the same or less than equivalent USB 2.0 product. Latency-wise, comparable with USB 2.0.
>
> In terms of how many I/O, I think that was still being calculated and experimentation was going to be required. Obviously options for 4, 8, or 16 I/O would be nice.
>
>
Did anyone have a good reason for not including support for a
usb-1.0/2.0/3.0 interface seeing as we can write the driver ourselves
and adhere to the standard?
Most chipsets these days have support for both port types. It would be
very useful if the schematic provided tracks for both ootb.
BTW, I will be able to contribute development funds towards this project
if required once we have a BoM.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
I've built the Synthesis ToolKit and want to install it, but make
install Is there an easy way?
I can't install the package for my distro because I've got zero audio
packages installed - all built from sauce.
James.
