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.
Hi.
I recently got myself an ADS InstantFM USB radio tuner card.
This is exactly what I always wanted, a tuner with a built-in
USB soundcard, so no need for loopback cables or anything.
It also happens to have RDS, which can be programmed from
user-space since 2.6.32.
So to celebrate the release of 2.6.32, I wrote a small
command-line tool (basically for myself) to work with that
card. The tool impelemnts the following features as of now:
* Decode most important RDS messages (program name, radiotext)
* Allow for playback via JACK or ALSA
* Allow to record to an OGG file
The recording and playback features are currently implemented
using helper tools: arecord, aplay, oggenc and alsa_in.
Here is the URL:
http://delysid.org/linux-si470x.tar.xz
Future ideas:
* Write the capture and playback code in C to allow for:
* Stop during playback, buffering the audio for later playback.
* Record during playback like time-machine: Buffer a defined amount
of audio from the past, and use it when the user requests
recording.
* Maybe integrate libSoundTouch for realtime pitch shifting and
time compression (if playback is behind realtime).
If you have such a card (luck you!) give the RDS decoding a whirl.
Patches of course always welcome.
P.S.: A very good existing tool for realtime playback
of audio for this tuner card is mplayer:
mplayer -radio adevice=hw=2.0:arate=96000 -rawaudio rate=96000 radio://91.2/capture
If all you need is this, by all means, go with mplayer.
linux-si470x is more geared towards integrating RDS decoding
into a command-line tool for operating these tuner cards.
P.S.2: Version 0.1 of linux-si470x is now 2 days old.
So this is indeed a very early pre-release. But since I didn't find
anything equivalent, I thought I'd release it anyway in
case someone can make early use of it.
--
CYa,
⡍⠁⠗⠊⠕
On Tue, Dec 01, 2009 at 10:57:58PM -0800, Ken Restivo wrote:
> Really? A huge number of tracks I've published, were
> mixed in Ardour freewheeling mode, using jconv for
> reverb. Worked fine for me, at least with the older versions.
You've been lucky :-) This will probably still work with
the new version (maybe even 'better' as the result of a
bug fix), but it's not by design.
In theory zita-convolver could be modified quite easily
to work correclty in freewheeling even on MP systems.
The complicated part is switching between normal mode
and freewheeling 'on the fly' - I've not worked out
how to do that correctly.
But as said, on a single processor system it will work.
What is happening is this: zita convolver uses some
processing threads that effectively run with a period
that is a power-of-2 multiple of Jack's basic period.
They run on RT priorities just below the one of Jack's
process thread (-1 for for each doubling of the period).
The output of these threads must be ready when their
next period starts.
Zita-convolver checks this condition and will report
errors if these threads are too slow, but it will not
wait for them - you're not supposed to wait in Jack's
callback, and if your system does support the CPU load
for the given configuration they will be ready, even
with some safety margin.
When freewheeling, Jack's main process thread will be
non-RT, while these extra threads remain at RT. So
they will pre-empts Jack's thread and will appear to
be always ready on time. Except when you have 2 CPUs:
then Jack's thread will be allowed to continue even
if some of the others have not yet completed their
work.
The issue is complicated a bit more by the way these
threads are scheduled, it is *not*
(viem with monospaced font)
1 1 1 1 1 1 1 1 1 1
2 2 2 2 2
4 4 4
8 8
but
1 1 1 1 1 1 1 1 1 1
2 2 2 2 2
4 4 4
8
i.e. in each period at most one one them
is at its longer period boundary.
Ciao,
--
FA
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
Is anyone on the list familiar with running jack and and a rt kernel on an
arm based board (beagle board or similar). I'd like to make my own embedded
guitar fx module using rackarrack and ldaspa plugins controlled via midi.
Without the hastle of always having to bring my laptop with me.
-wirelessdreamer
