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
Dear fellow FOSS enthusiasts,
This is probably already old news according to Internet standards but as it
turns out we spent a good time this evening in class not knowing that we got
slashdotted. For those interested in belatedly joining the discussion,
please visit:
http://entertainment.slashdot.org/story/09/12/03/2018253/Introducing-L2Ork-W
orlds-First-Linux-Laptop-Orchestra
Best wishes,
Ivica Ico Bukvic, D.M.A.
Composition, Music Technology
Director, DISIS Interactive Sound & Intermedia Studio
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/
This is a quick guitarix update to cover the new release of jconvolver eg. jconv
guitarix is a simple Linux Rock Guitar amplifier and is designed
to achieve nice thrash/metal/rock/blues guitar sounds.
Guitarix uses the Jack Audio Connection Kit as its audio backend
and brings in one input and two output ports to the jack graph.
To cover the renaming of jconv to jconvolver, guitarix-0.05.3-1
looks now first for jconvolver, if it isn't installed,
it looks for jconv.
Also a patch from Michal Seben (OpenSuse) is added to cover a build fail
at openSUSE:Factory.
Thanks Michal. :-)
Additional, there is a (rt) 2 Channel delay chooser for the output to jconv,
and the Chorus effect work in Stereo now.
have fun
________________________________________________________________________
Project page with screenshots:
http://guitarix.sourceforge.net/
download:
http://sourceforge.net/projects/guitarix/
________________________________________________________________________
For capture, guitarix uses the external application
'jack_capture' (version >= 0.9.30) written by Kjetil
S. Matheussen. If you don't have it installed,
you can look here:
http://old.notam02.no/arkiv/src/?M=D
For extra Impulse Responses, guitarix uses the
convolution application 'jconv' created by Fons Adriaensen.
If you don't have it installed, you can look here:
http://www.kokkinizita.net/linuxaudio/index.html
I(hermann) use faust to build the prototype and will say
thanks to
: Julius Smith
http://ccrma.stanford.edu/realsimple/faust/
: Albert Graef
http://q-lang.sourceforge.net/examples.html#Faust
: Yann Orlary
http://faust.grame.fr/
guitarix is licensed under the GPL.
regards
Hermann Meyer & James Warden
------------------------------------------
Am Donnerstag, den 03.12.2009, 14:04 +0100 schrieb Hartmut Noack:
> hermann schrieb:
> > I'm happy to announce a new guitarix release
> >
> > guitarix is a simple Linux Rock Guitar amplifier and is designed
> > to achieve nice thrash/metal/rock/blues guitar sounds.
> > Guitarix uses the Jack Audio Connection Kit as its audio backend
> > and brings in one input and two output ports to the jack graph.
>
> Nice one, thatnk you :-)
>
> I love to see this project grow - a simple works-right out of the box
> amp for Linux is extremely welcome.
> BTW: do you think, you could turn it into a LV2-plugin?
>
> Some people could consider then to boost stability and performance of
> their Linux audio system by dropping VST via WINE....
>
Thanks Hartmut, good to hear that you like it. :-)
Make guitarix a LV2-plugin, is at least a question of development power.
We would love that to, but, Guitarix is a young small project, we are
only 2 developers, and we both have at first other tasks in mind witch
we wone implement.
In fact, it will be easy for a bit experienced LV2 developer to port the
"control chain" of guitarix to LV2.
Our source is spiked with comments witch make it easy to jump in and
grep the needed source.
Guitarix is a open Project, open for developers who wone join the
project.
gruß hermann
Hi everyone,
I just started writing my first c++ program, and I'm kind of stuck with
something I cannot understand. After a few days of trying to figure this
out, I decided to ask for more professional help. I'm working on a kind
of arpeggiator for linux (which I intend to release under GPL).
The program uses a text file, in which the user can specify a number of
arpeggios. Each arpeggio is loaded into an object called 'Arp',
and for every Arp I make a jack port, and a ringbuffer.
(the port and ringbuffer are stored in an object called Arp_jack)
A seperate thread, watches the text file for modifications (using
inotify), and every time the file is changed, the file is loaded afresh,
and the new Arps are put in the respective ringbuffers. The ringbuffers
have a size of two Arps, and the idea is that when a new Arp arrives,
the old one is discarded. If there is only one Arp in the buffer, the
program keeps on reading the same one.
This code is part of the inotify thread:
while (i < len)
{
struct inotify_event *event;
event = (struct inotify_event *) &buf[i];
if ( event->wd == wd )
{
vector<Arp>* arps = new vector<Arp> ;
read_load_file( arps ) ;
for( uint x = 0; x < arps->size(); x++ )
{
const char* arp_char = reinterpret_cast<const char*>(&(*arps)[x]);
jack_ringbuffer_write( (*ARPS_JACK)[x].rb, arp_char, sizeof( Arp ));
}
//delete arps ;
}
The next code fragment comes from the process callback. As you can see,
I'm using jack_ringbuffer_get_read_vector to read the raw data, and I
advance the the read pointer when a new arp is available:
if( (jack_ringbuffer_read_space( (*arps_jack)[i].rb ) ) ==
(sizeof( Arp ) * 2) )
{
jack_ringbuffer_read_advance( (*arps_jack)[i].rb, sizeof(Arp) ) ;
}
if( (jack_ringbuffer_read_space( (*arps_jack)[i].rb ) ) ==
sizeof( Arp ) )
{
jack_ringbuffer_data_t data[2] ;
jack_ringbuffer_get_read_vector( (*arps_jack)[i].rb, data ) ;
if ( data[0].len > 0 )
{
arp = reinterpret_cast<Arp*>( data[0].buf ) ;
steps = &arp->steps ;
scale = &arp->scale ;
}
else if( data[1].len > 0)
{
cout << "data in second part of ringbuffer, this should not
happen!" << endl ;
}
....
Now to the question. The code works as I expect, as long as I don't
delete the vector of arps in the inotify thread (see the commented
line). When I do delete the vector, the program segfaults.
(and also when I allocate the vector on the stack, and it gets cleaned
up automatically)
I thought that writing to the ringbuffer with jack_ringbuffer_write
copies the data to the ringbuffer, so I don't understand why this should
have an influence. Is it a problem that I put the ringbuffer in
an object which is accessed by two different threads without using a
mutex? I've tried using a mutex,but I still had the segmentation fault.
Any help with this would be really appreciated.
Thanks for your help,
Lieven
Seing that HDMI interfaces are getting implemented everywhere - a bit
like S/PDIF before that, but now with 8 uncompressed channels @192k and
24 bits - does anybody know what kind frame sizes are used and what the
implications would be for realtime audio-processing? (.. as opposed to
buffering up and re-playing pre-recorded material from a DVD.)
Not that I am aware of anything reasonable to connect to at the
receiving end yet - but who knows, that might change.
On Wed, Dec 02, 2009 at 12:39:27PM -0800, Ken Restivo wrote:
> Does the "partition" parameter in the conf file affect this?
Yes, it determines the minumum partition size that will be
used. The only difference between the two examples I posted
is the value of this parameter, 256 or 4096.
> On the reverbs I've been using successfully with freewheeling
> mode, the "partition" is set to 2048, which is very high compared
> to the setting in the sample reverbs tthat come with jconv.
Which means you will have significant delay. If the reverb is
use as an effect (rather than to recreate real room acoustics)
this could actually be beneficial.
On a single processor machine freewheeling should just work,
and not depend on this paramter.
Ciao,
--
FA
Wie der Mond heute Nacht aussieht !
Ist es nicht ein seltsames Bild ?
lieven moors:
>>
>>> I want to repeat the same Arp, until there is an update to the text file.
>>> One arp is allready
>>> loaded in each ringbuffer in main(). When the file is modified, a second one
>>> is added, and
>>> process skips to the second one. Since I have only space for two arps in the
>>> buffer, there
>>> should always be exactly one which is readable. I know it is a bit weird,
>>> but it seems to
>>> work, apart from the problem I described.
>>>
>>
>> sounds as if you might want to look into atomic pointer and/or integer
>> exchange instead, to get lock-free double buffering.
>>
>> ringbuffers are generally for passing streaming data/events.
>>
>>
> Could you give me a hint on how to use atomic pointers?
I've used the lockless lifo/fifo-queue implementations found in
midishare a few times. Those are really simple to use:
http://midishare.sourceforge.net/