Hello!

I need some software that could alter the sound input of the microphone in realtime. Mainly it should have the possibility to modify the pitch/timbre/octaves (much like the AV Voice Changer from Audio4fun) and work on linux with ALSA. So far i've found some programs that are able to distort/reverb the sound input but none are able to alter the pitch/timbre of a human voice to resemble a different voice, and windows applications (with Wine) which do that crash because of failing to directly access the soundcard. Commercial software is also welcome. Any suggestions?

Thank you in advance!

I admittedly don't have alot of experience in this area, but I hear good things about audacity.

I will give it a try, but I don't remember audacity being able to do real-time alteration.

http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page
http://svnweb.tuxfamily.org/filedetails.ph...D-PACKAGES-LIST

This is going to come-across rather negative... I apologize for that...


PCs are not that good at real-time audio processing. This is mainly because of the multitasking operating system (Windows, OS-X, or Linux). These are not real time operating systems, and in order to get continuous audio, you need to use input and output buffers. The buffers can keep data flowing at a constant-smooth rate, but the buffers introduce a delay. The delay is required, because without a delay, the data-flow (audio) will stop when the process is interrupted by the multitasking system. (The operating system is always doing stuff in the background, even if you are only running one application... i.e. The mouse and keyboard wouldn't work if the operating system didn't interrupt your application every few milliseconds, and of course the drivers need some CPU-time, etc., etc., etc.)

The more exotic the effect, the more difficult it is for a PC to do it in real-time. And, I would consider pitch and timbre to be exotic effects... They are computationally complex.

Also, real time effects usually imply a live performance. This requires reliability, which means you probably need a back-up computer. (The average computer is way-less reliable than the average piece of audio gear.)

Most serious audio work that is done with computers is done on Windows PCs and Macs. (I've got nothing against Linux, but most audio software is designed for Windows or OS-X.)

theres a ton of nice software in the planet ccrma linux distribution. http://ccrma.stanford.edu/software/

for example sooper looper is a great real-time looping tool. you can also use jack (i realise you said alsa) and use the jack rack to run any sort of plugins you want.

im not TOO up on linux, but i think you might be able to hook up to the ccrma repository and then just do yum -install for any of the programs on it.

for real-time voice effects, just this morning i was using rt-lpc, although the effects are all geared towards lpc and so might not be what you are up to. still, it does pitch shift and awesome voice-distortion :]

http://soundlab.cs.princeton.edu/software/rt_lpc/

i also want to direct you to Chuck, which, while not realtime 'out of the box', you can very easily write ANY sort of real-time processing algorithm you need. i've done this to decode a time-coded vinyl for turntable manipulation of digital data. programming required, but so rewarding.

chuck: http://chuck.cs.princeton.edu/

DVDdoug,

I can get roughly 1ms delay with my RME, from input to output... through ASIO or Kernel Streaming. So saying that PCs in general don't have low latency is... inaccurate.

There's several radio processors that are now using PCs, and the new trend even in DSP processors is to have modular multi-core multi-tasking "CPU-esc" architecture - because of how re-tool-able generic multitasking architectures are. (see OmniaONE, for instance)

And even the "older" style DSP units are all running multi-tasking code, often ANSI C... and many units are actually running Linux for the front-end controls, and logistics like IP connection, firmware flashing, etc.

And it's not like PC-based processing is just being used on some pirate station in the mountains of Siberia or something. Heck, even the SuperBowl a few weeks back was processed with an audio processor running on a PC platform, by Linear Acoustics.

I reject your reality, and replace it with my own.

"Rosegarden" is similar to "Logic Audio".
But it's such a complex program I don't think is even easy to install.
http://www.rosegardenmusic.com/

For WAV/FLAC/MP3 editing and manipulation, Audacity works.
It's not a "CoolEdit", but gets the job done depending on what you want.
Next version 1.4 probably will look nicer because the GUI is kinda ugly.

This isn't my area of expertise, but check out this open sourced version:
http://ardour.org/

Thanks for all the replies guys. I realise that a computer does not work in true "real-time", but the delay is not critical for what I need.

I think I'm going to stick with the software from ardour.org. Looks quite promissing.

Cheers!

linky:
http://en.wikipedia.org/wiki/Linux_audio_software
http://linux-sound.org/dsp.html


later

If you can do pitch shifting & timbre adjustment with 1ms latency (in software), I take it all back! I don't know what kernel streaming is, but I do know that a kernel mode driver can take-over and "hog" the CPU. And, anything's possible if you can bypass the CPU and data bus by using a hardware DSP.


jesseg, Don't take my "argument" too seriously. It sounds like you know more about this than me... I'm only an amateur-hobbyest programmer....


I sure hope they have a backup! And yes, a dedicated computer/server is more reliable than a general purpose machine that gets "messed with"... Most "reliability issues" are caused by the user, or by a misbehaving application. Even so, PCs do have hardware-failure rates higher than most electronics... They are more reliable than copy machines! Linear Acoustics seems to be selling hardware... I assume the PC was simply used to control the hardware.


The "front-end" is not a problem... I assume the front-end stuff is running on it's own CPU, separate from the DSP unit. It also helps alot if you can design the hardware & software together and maybe tweak the O.S. There are even real-time versions of Linux, but AFAIK, they don't run an a PC. (I'm sure RTOS Linux could be adapted to run on a PC, but then none of the standard applications or drivers would work...)

I think you have a general mis-conception about how a DSP processing system works. And I would say easily 75% of the blame is in false marketing claims (in & out of adverts) by companies who have invested a lot of money into "old-style" DSP chips, and need to keep status quo to keep their customers from feeling like they got ripped off. The problem, for them, is that this issue only gets worse for them the longer they keep lying to people.

As far as delay for performing a processing function... let's assume that we're going to be compiling the same ANSI C code for the DSP-based unit, as well as the CPU-based unit. There would be zero difference in the amount of latency each platform takes to perform the operation on the block of samples. The processing latency, if any, would be coming from the code itself. The real life latency would be a combination of that, and the hardware's AD/DA converter latency.

That being said, I have never heard of a truly real-time DSP solution that can process and output analog signals of any kind. At this point in time, there is at least some delay in the AD/DA conversion process. People will probably figure out a way to get around this, and get people to buy into it, some day... but it won't be PCM based. As far as digital processing being true zero latency, that's also not ever going to be possible with PCM. With PCM, there will always have to be at least 1 sample (or more depending on number of channels) latency on the processing. Any additional delay in the digital world is 100% just the code itself - not a function of the platform the code is executed on.



I bet they had multiple backups, and failsafes too. I bet they would have regardless of what they were using for audio processing. I bet the had multiple backups of nearly every technical device they used throughout the entire event - from duct-tape to the multi-million-dollar trucks used to "paint" the graphics onto the field.



Not necessarily.



You assumed wrong. It's all running on a single well-tuned WindowsXP Embeded OS, loading from Flash Memory. It works just as long and hard as an old DSP-based unit, is BY FAR the most used audio processor for TV stations that are sending out surround-sound, and they can be easily retooled COMPLETELY to perform any other function. Something most DSP-chip-based units can't boast about, which is partly the fan-fair surrounding boxes like the OmniaONE. (but it's still a rip-off from a hardware cost standpoint)



Because RTOS isn't really made for anything you would actually be using or interfacing with. In fact i'm not sure why someone would even bother to put an application RTOS is used for, on top of a Linux kernel. After reading the wikipedia article about it, the only reason it seems to be called an "OS" is because it has a thread handler for whatever unit is handling the core processing task. Kind of a weak excuse for something to be called an OS imo, but just the same... an RTOS is not something anyone should consider using for processing audio. It's really not setup for that. If fact I'm not sure who would actually be using an actual RTOS these days, except for in things like the operating of the AC power system, or in a nuclear power plant or some such - and even back when they first started, they were using UNIX. I personally know the guy who developed the thread handler for the kernel that's still running in most of them.


I'm sorry, everyone else, for going so far off topic. Suffice to say most modern real OSes are just fine for use as near-real-time audio processing. It's just a matter of having the right hardware, and stripping down the OS to achieve whatever your desired results are - like fitting onto a 128MB flash memory, or for stability purposes. Actually, WindowsXP just by itself, without much tweaking, is pretty dang freakin stable for audio. The only problem I've ever had with WindowsXP SP1 & SP2 in an installation environment is the Windows Audio Service will literally just not make any more sound, no matter what, after exactly 365 days of uptime. I bet i'm one of very few people on this forum (if any) who have ever been able to test that bug, with over 100 systems, all at the same time. Now THAT was a fun day. lol.

Broadcast TV is not a real time problem, you can accept almost any processing delay as long as it is constant. The processing delay for MPEG encoding for cable TV transmission is going to dwarf the audio processing delay through almost any conceivable box.

Live sound processing for musical theatre is time critical. You *must* keep the processing delay between the original sound from the source and the reinforced sound from the PA below 5ms otherwise people will notice phasing errors.

The average digital mixing desk has a delay of somewhere between 1 and 2ms, you might also put your signal through some outboard processing which adds a millisecond or two and probably a loudspeaker management system which also adds millisecond.

Some of the standard boxes for live sound reinforcement are BSS SoundWeb London

http://www.bssaudio.com/products.php

These boxes are FPGA based, you decide on your signal chain and the SoundWeb software compiles it into a custom processor which is programmed into the FPGA. This is all done to minimise latency and maximise the number of channels that can be processed simultaneously.

Yea I definitely wouldn't consider using broadcast audio processing for live audio reproduction anyways, unless it's some small mobile DJ rig or some such. And even then, you don't need a ton of power.

Very nice stuff on that link you provided. It looks like a blast to use for installations. It's been years since I've made it back around the way of checking out the stuff that got me into audio processing in the first place; the DSP and controllers for the 80kwatt Turbosound Floodlight touring system I used to own almost 10 years ago.

Getting back on topic, I thought it would be appropriate to post this... interesting piece of software & hardware:
http://www.jesusonic.com/
I'm not so sure about jesus being happy about it's sonic integrity, but you gotta admit it's pretty. It's now part of Reaper, which is unfortunately not ported over to Linux yet. I gotta wonder hoe much "awesomer" of an interface could be made with some Doepfer controllers;
http://www.doepfer.de/home_e.htm