Audio and Python

Why not use a wave player, or players, and use Python to control the playback and routing?

Hi Per-

How many signals do you need to play back at the same time?

How many different audio clips are there to be played back?

If you want to play more than 6 audio clips at the same time, I would encourage you to look into some of the dedicated playback devices. Something like the Audio Science ASI 6416 PCI CobraNet card will allow you to play back 8 stereo audio clips at once and put them on CobraNet. Your NION can take this CobraNet and route it to the system outputs you desire. Or, of course there are many other devices from the likes of Alcorn McBride and others who are into the higher numbers of playback channels.

Thanks!

-Josh

Hi and thanks for many good suggestions.

We're actually using the Alcorn McBride 8TraXX (please - I'm dying to hear about all evil rumours, per@sound.se). We've used it before and it seems to work fine - so far (but you're making me nervous now) .

Haven't looked into the Binloop, but it seems like a good idea if you can tie them together using CobraNet.

The tricky part is the audio processing bit: In this installation, people can speak (sound) and add chunks of audio to the complex. I've made a Python script that randomly, and at random time intervals, selects one wave player out of four. The audio is processed using the existing processors in MM. But I would also like to add all incoming audio to an accumulator (with an exponential decay) to create a gravy of all audio ever added. This is art !

Maybe I can achieve this by using a delay and a feedback loop with a gain slightly less than unity...
Merry X-mas to you all.
Per

Oh. My.

Per- What an interesting way to use the NIONs ability to record and play audio! Now you have me really interested! How do the people speak into the system? Do they have to push a button or anything like that? Do you have a defined limit for how long their entry can be? Do you have a method of purging tracks after some predetermined amount of time, or do they just accumulate over time? What will happen when you overload the storage capacity of the NION? Would you be willing to share any of this with us? I know I would be very interested in looking at your project design even if you would prefer that we not use it as an example of what can be done.

Thank you for sharing what you have so far! If you would rather not share on the board, my email works... there is a link right under my name.

-Josh

Ya, I've used that to add some Python modules that don't come w/ the Nion. AFAIK the MontaVista version you guys use seems to have most of what one would expect on a typical *nix host. So many ways to void one's warranty I don't even know where to begin....

With regards to the parent thread, the more I think about it, the more I would prefer to handle all the recording/playback in the storage host rather than the Nion. Use the Nion to route and apply what ever processing(high pass, comp/limit) you like to the record stream. The PCI Cobranet card eliminates the issues of transferring media between the Nion and storage server, not to mention the 'uncharted waters' nature of doing so w/o using Nware. No messing with FTP, whining about NFS, etc. Use the Nion for what it is good for, and use the server for the rest.

Hi guys.

The solutions you have discussed so far are very interesting, although I don't fully understand how this should be implemented. And with the time schedule (and budget) for this project in mind, I really hope that the capabilities of the NION Nx will do. I haven't seen a NION until three weeks ago, but I'm trying hard to learn as much as possible about this thing and it doesn't look too bad right now. There are still some open ends, though, so I'll make a short presentation here.

I work with this group, Urban Sound Institute (www.usit.nu), comsisting of two musical composers, two architects and me, who is a sound designer/producer/acoustician. I used to work with research in adaptive filters for active noise and vibration control.

We're doing this installation in a museum in Sweden. In a big hall we've built a labyrinth (approx 8 by 13 meters) that is ment to be pedagogical as well as entertaining. It has has four different sounding parts: The name, the story, the music and the room (with long reverberation). In all theese we're running pre-recorded sounds (with the 8TraXX = 16 channels of sound). In three of theese, (the name, the story, the room) people can add sounds.

The name: A push button, connected to one pin of the GPIO interface, starts a recording. The length of this recording is preset to something between 3-5 seconds. I've got four recorders, recording to files name1...name4. A python script decides which recorder to use. This is usually the next one in line, but if the corresponding file is currently used by a player, the second next recorder is picked. Four players are designated to play theese files. A pyhton script selects players randomly (avoiding the player that corresponds to a file currently beeing recorded) and at random times. This means that a maximum of four players/recorders will be running simultaneously. The names are played clean as well as processed and mixed with a pre-recorded marinade.

The story: In this case, lifting a telephone receiver starts the recording (another GPIO pin). The recording continues as long as the receiver is off the hook, or until a preset time limit is reached. As before, there are four recorders recording to story1...story4, respectively. A python script decides which writer to use and as before, I'm not recording to a file that is currently beeing played back. The stories are played back one after the other, again controlled by a script. This was quite tricky to write, since the playback has to work even if e.g. only one file has been recorded, so I maintain status flags (in the state variable) on files written.

You raise a good question here: What happens when I run out of disk space? The answer is: I don't know! (Yet!). In fact, I don't even know how much space there is to store data in. How can I find that out? My unit was shipped with the 256 Mb disc and the problem would definitely be smaller (I imagine) if I had the 2 Gb disc. I'll talk with TTS (your associate in Sweden) about this.
I don't know how clever the file system is, but I imagine it might become clogged after a (short) while. Maybe a solution would be to clean the disc once a day. How do I do that? Automatically?

The third place is just a room with long reverberation: A microphone in the room is fed back through loudspeakers with delay and reverberation, mixed with pre recorded material. The Feedback Ferret comes in handy Nothing is recorded or played back on the NION.

To save DSP time and disc space, I'm running the system at 24 kHz sampling rate, but somehow it seems that the CABs are still running at 48 kHz (I need to interpolate). How's that? I'm also getting compilation notes saying "Device has sample rate override† that makes me a bit confused.

This was the short vesrion.
I'm wide open to suggestions.
Per

Hmm - read the manuals (again) and saw that the CAB 16i/o only run at 48 kHz.
Maybe it's still a good idea to run the NION (and its IO cards) at 24 kHz and do the decimation/interpolation to interface the CABs (one CAB 16i and two CAB 16o).
Cheers
Per

A general purpose *nix machine running a database does indeed address the tasks that the Nion may not do so well. If you do find that you need(or want) to add this level of functionality at a later time, the Nion need not be replaced. It is a rather simple to recode your existing Python scripts to instead control the server(likely via a socket) as opposed to the wav players/recorders currently residing in the Nion. All the GPIO interfacing is probably fine. By using Cobranet to interface between the Nion and server, the physical wiring changes that would be required are pretty much nil.

Speaking of sockets, it seems that Nions do have the standard Python socket module available.

Good luck...

Hi

It seems that the CPU load is around 10%. 5M is around 1.3 (if I remember correctly). What is this indicator anyway? There's another one too, right? 15M? (I'm not by the machine right now).

The DSP load is on average around 25%, but the DSP memory blocks 0 and 1 are used up to 99%. I've had to specify the DSP (A, B or C) for some DSP functions for the compiler to go through. The shared memory is used to 2%. Is there any way to make better use of this memory capacity?

The big question is still how much disk storage space there is available for storing wave files. Is there any way for me to find out? I think I read somewhere that the Python OS modules are not included in the MM implementation.

Per

PS. We're going live in two weeks...