What I would like to do involves a small bit of hardware. 1) a phone headset, 2) a PCI-modem, and 3) a phone wire. What I would like to do is read audio from the modem, and then digitize it for processing. I'm sure the best way to do this is with Linux, but if it can be done in Windows as well that would be awesome. A second extension of this, is that I would like to be able to translate digital audio to analog audio and send that to the modem so it can be heard from the headset.
Any advice would be greatly appreciated. ( Also, if anybody has a general "pointer" to what I should investigate to replicate the audio stream to a TCP server so it can be accessed over LAN, that would be even cooler. I know how to handle TCP well enough, but I haven't a clue about audio encoding / decoding ).
If anybody's curious, I'm wanting to create a home-wide audio-stream with ears and mouths. Since the phone cables can do that with normal headsets, I thought "why not".
Not just any modem will do. You need a "voice modem", which includes audio capability as well as general modem functionality. These devices usually expose themselves as a regular sound card on the system, once the drivers are installed. From there, you can use any mechanism you want to read/write from those audio streams.
Be warned though that your plan of a whole-house speakerphone isn't simple at all. There are significant feedback issues when using regular POTS lines. There are entire companies that work to solve this problem. The best of them use microphone arrays that are steerable in software. You would be better off using one of these off-the-shelf systems.
Related
So I'm kinda stuck here.
I have a radio station, but we are mobile. So I have a studio on wheels. The problem is, we have an antenna, but we always have to place that really close to our studio. Now I want to make an device that can stream the audio from the audio mixer to the internet and can be received by another device in another network and send that signal to the antenna (audio output).
to make this clear, I made a schema with raspberry pi's;
I want this to be plug and play So I only have to plug in the device in the modem (or network we have) on both sides and the devices should find each other.
I don't know HOW I can do this, so I need to know a couple of things:
What hardware should I use?
What software should I use?
What is the best configuration to accomplish this?
Can I use 2 raspberry pi's?
How can I let the devices find each other over the internet?
There need to be some features;
The system needs to be able to buffer the audio for 5-10 seconds
It needs to be direct, so it's live and not a file that needs to be played
The system must be failless (beside the fact the internet can die).
Plug and play is a must, I don't want to have a really messy configuration to do. (if possible, without any kind of portforwarding).
I would really appreciate help and a decent explaination.
regards,
Robin
Well, it depends on your capabilities as a programmer.
If you're really fixated on the RPi for it's convenient form factor, there's a ton of community support, so I'd start with something like this project to kick start you in the right direction. If you already know python pretty well, modify away and have fun.
If you have no programming experience, you'll probably want to put a desktop in place of the RPi and launch some instances of VLC. It's not necessarily plug n play, but you can get close enough by getting a command line VLC to launch at startup.
Either way, the more difficult problem here is the "over the internet" part. This would really need to be a server-client model, but who is your server depends on who is more stationary (I'm guessing Location 2?) because the client will need to know the IP address of the server somehow. There are dozens of ways to make this happen, but at the end of the day, you'll want to use sockets accomplish the
It needs to be direct, so it's live and not a file
... which unfortunately gets complicated. See this answer for confirmation. Would love to help with some tips on implementation, but we need more information about your willingness to "dig into the code", the necessity of the RPi, and whether the stationary location has a static web address.
I have 5 requirements:
I want to send sounds that are output of other programs over voice chat programs(e.g. TeamSpeak, Skype etc.)
I only want to send the sounds of certain programs. Not all my system sounds
I must still be able to talk to them (mice input should still be used).
I still want to hear the sounds of what I send.
It must be a software solution.
My scenario:
I am playing LoL/DoTA/CoD/BF (whichever makes you happy), I am on Teamspeak with some friends. Something happens and I want to play a fitting sound (e.g from http://www.myinstants.com/). So I want to send the sound from my browser over the chat.
What I tried:
I installed CheVolume (http://www.chevolume.com/Infos.aspx). This is for handling output devices, not sound input.
I set Stereo Mix as my default communication device. This works mostly, but then I also send my game sounds over chat.
I have installed VB-AUDIO (http://vb-audio.pagesperso-orange.fr/Voicemeeter/). It can be useful, but it is not what I want. I get similar results as using Stereo Mix.
I installed Jack (http://jackaudio.org/) shame to say it is to technical for me.
I tryed using Virtual Audio Cable (http://software.muzychenko.net/eng/vac.htm). Again, this only enables me to send all my system sounds.
but Voicemeeter allows to do that:
Exactly : See User Manual Case study #1
it is possible only if the application allow settings its playback device, then you will be able to route an application Voicemeeter virtual input or physical input through a VB-CABLE (Voicemeeter Banana version is better for that since it provide more I/O)
3,4,5: of course.
I am to test voice recognition programs. Some which I have access to the code and others where I don't.
Sadly my (beautiful) voice is not perfect, so when I am reading a text it sounds slightly different each time. Which makes the testing difficult and time consuming. Giving that I can tweak a lot of parameters.
So I was wondering if there was a way to record my own voice (already done). And then play it as normal microphone input so the voice recognition program I am testing will see it as microphone input.
This would also help greatly if it could be done programatically in C#. So I can in my own code specify when to play what.
To play it from speakers and have the voice recognition programs listen to the microphone is not an option, because it is not the same sound on different computers/speakers/microphones.
Thanks.
Edit:
What i have found so far is to use a software sound Card simulator. But I haven't been able to find a suitable one.
Just as there are printer drivers that do not connect to a printer at all but rather write to a PDF file, analogously there are virtual audio drivers available that do not connect to a physical microphone at all but can pipe input from other sources such as files or other programs.
I hope I'm not breaking any rules by recommending free/donation software, but VB-Audio Virtual Cable should let you create a pair of virtual input and output audio devices. Then you could play an MP3 into the virtual output device and then set the virtual input device as your "microphone". In theory I think that should work.
If all else fails, you could always roll your own virtual audio driver. Microsoft provides some sample code but unfortunately it is not applicable to the older Windows XP audio model. There is probably sample code available for XP too.
I'm evaluating building an application which, simplifying the requirements, records from a microphone equipped small computer (eg: a Raspberry PI) and streams the digitalized sound over wireless connection in almost realtime to a server on the same LAN (No Internet involved). Ideally, the server application would record different streams from various wifi microphones and mix them together..
I'm currently looking into obtain a pretty good quality out of this, comparable somehow to a 128Kb stereo MP3.
At this point, I'm still evaluating options here, so I'm also looking to see your opinion on the feasibility of this.. if you think it's doable, what libraries, APIs, protocols would you use? Consider that this will be likely deployed on Linux based embedded computers (for the wifi mic part) and Linux based servers.
Thanks for your help.
I listen often Shoutcast on the iPad. This sounds pretty good to me. I do not know the kb/s rate there, I think they stream mp3. So I do not think this would be a big issue if you can live with the quality loss which comes with mp3. The bigger issue might be, how good your wireless connection is. When your network is pretty busy, there are more errors and lower speed. It also depends on the wireless standard and the hardware you are using. You may think about buffering, too.
I was wondering whether it is possible to capture audio data from other sources like the system out, FM radio, bluetooth headset, etc. I'm particularly interested in capturing audio from the FM radio and already investigated all possibilities including trying to sniff the raw bluetooth communication between the phone and the radio device with no luck. It's too bad Android only allows recording audio from the MIC.
I've looked at the Android source code and couldn't find a backdoor to allow me to do that without rooting the device. Do you, at least, have any idea how to use other devices (maybe access somehow /dev/audio) say via NDK or even better - Java (maybe Reflection?) to trick the system to capture the audio stream from say, the FM radio. (in my case I'm trying to develop the app for the HTC Desire)
PS. And for those of you who are against using undocumented APIs, please don't post here - I'm writing an app that will be for my personal use or even if I ever publish it I will warn the user of possible incompatibilities.
I've spent quite some time deciphering the audio stack, and I think you may try to hijack libaudio. You'll have trouble speaking directly to the hardware (/dev/*) because many devices use proprietary audio drivers. There's no rule in this regard.
However, the audio hardware abstraction layer (HAL) provided by /system/lib/libaudio.so should expose the API described at http://source.android.com/porting/audio.html
The Android system, and especially audioflinger, uses this libaudio HAL to find available devices, deal with routing, and of course to read/write PCM data.
So, you could hijack the interaction between audioflinger and libaudio, by renaming the later, and providing your own libaudio which decorates the real one. Doing so, you should be able to log what happens and very possibly intercept FM radio output, provided that this is not directly handled by the hardware.
Of course, all this requires rooting. Please comment if you manage to do this, that interests me.