Currently I am working on a custom board having TPA3118D audio amplifier. The amplifier has 3 GPIO pins (Mute, Enable,Fault) which are controlled from the processor. We are able to hear the audio once I make the enable high from Linux running in the processor. I was thinking to automate this process by telling the Linux to make the enable pin high during the booting. This is where I am having the confusion. Is this the right approach? Is it okay to enable the amplifier as soon as the hardware starts or the Amplifier should be enabled only when we are playing the audio?
I would like to understand the standard approach for controlling Amplifier. How is the enable pin handled? Do we keep the Amplifier always ON or enable it during playback only?
Thanks in Advance.
Related
I have a bluetooth headset. When connecting it to Windows 10, it installs two profiles in Playback devices list:
Hands-Free. (HSP profile)
Stereo. (A2DP profile)
The Second one (Stereo) is set to be the "Default Device" and the "Default Communication Device" on the system.
When I start any program that uses the mic (recorder, chat, VoIP Calls, gaming, etc.) The sound suddenly stops working And I can only use the mic until I stop the recorder or the call.
To enable the sound again I need to make the Hands-Free (HSP) profile handle both input and output (sound and mic). Unfortunately, HSP gives really poor sound quality.
I want to know If there is a way, using code, I can change Bluetooth behavior so the two profiles work simultaneously. One handles the sound and one handles the mic so I can have high quality sound and use the mic at the same time.
You will probably never find a solution. I had the same problem (I was trying to create a walkie talkie with 2 headsets connected to the same smartphone).
On Windows (but also on Android) you can't access directly to a BT-microphone or BT-speaker because it is automatically detected as BT headset and the OS take the control of the device.
Your app can then access the OS-device and not directly the hardware device. The only OS able to do that was Symbian I think which had the most BT-protocols. On Windows you will probably never be able to do that and on Android you have to write your own A2DP-protocol if you want to access the device directly without OS interference.
So sad...
Luckily, under windows you can define different devices for communications and sound.
So, you have two choices:
Choosing Hands-free for both mic/speaker only for communication (which will switch back to A2DP after the call/teams).
Choosing another mic for communication which allow you to still use the speaker profile even in communication.
That is a bluetooth restriction : A2DP (high quality audio) cannot be use simultaneously with HFP (hands-free profile)
I have a USB audio device (Scarlett Focusrite 18i6) which does not require a driver, so I assume it uses the USB HID Audio Class standard.
It works on everything from Windows and Mac to Linux and iOS.
But on Mac and Windows, it has a control application which can for instance enable and disable direct monitoring.
How would I go about reverse-engineering how this is done, so that I can reproduce it on platforms where the control application does not exist?
I'm thinking of booting up Windows in a VMWare session and then logging the USB communication (somehow?) while using the control application, but it does sound tedious considering the amount of data and my very limited understanding of USB.
Any other suggestions?
You could try running the control application using Wine instead of reverse engineering it. However, if it's accessing USB devices then there is a good chance it might be using an API not supported by Wine.
To reverse engineer it, you should find a way to look at the USB traffic between the computer and the device. Total Phase has some hardware USB protocol analyzers, but you might be able to find a good software solution for free.
I'm looking for documentation on how to build an ADC Core Audio compliant to connect to a mac USB or Firewire. All I've been finding is info on how to deal with Core audio on programing the computer side.
I need info on how to make audio hardware Core Audio compliant.
Can anyone send me the right direction?
This a nice solution. It does all the hard work for you. If you have even basic hardware engineering experience this should get you on your way. This chip will work great. Very few external components needed.
http://www.silabs.com/products/interface/usbtouart/Pages/usb-to-i2s-digital-audio-bridge.aspx
I have developed a pretty complex audio software for my client with plugins for Winamp, Windows Media player and VST. Now the client is interested in some method to avoid maintaining the multitude of plugins, we have no way to support all the media players out there.
The client does not care for Unix/Mac yet, so I can look only at Windows XP and Vista/7/
Basically, what we need is a way to always reliably intercept as much audio stream protocols as possible (well, except maybe ASIO, that's another story, I guess), then pass this audio through our custom effects engine and then route back to the default audio device, whatever it is.
Now I am thinking, what options do I have (theoretically).
I could use hooks. I need to hook globally older vaweOut and also DirectSound.
But will this still work on Vista/7?
I could use a virtual driver, like the author of the Virtual Audio Cable did:
http://software.muzychenko.net/eng/vac.htm
Seems a pretty daunting task. Anyway, the client will contact the author of VAC to see if he agrees to sell his source code for a reasonable price.
This driver could install itself as a default audio output device, intercept the audio stream from Windows, and pass it back to default device. Hmm, but what about various DirectSound audio buffers, do I have to mix them myself or is there any way I could tell Windows mixer to mix all for me and pass a single mixed audio stream?
It seems, this custom driver will of course kill all the hardware audio acceleration, but we can live with that, if we warn our customers about this issue.
As I understand, the most current Windows driver standard is WDF.
But maybe it does not work for audio on Windows Vista/7?
I know, Vista/7 has a different audio stack from XP.
If I can do it using WDF, what driver should I write - kernel mode or user mode?
Maybe I am missing more elegant and simple options to intercept, process and route audio on Windows?
Try Virtual Audio Streaming SDK. Also virutal sound card and let you read/process audio data in realtime.
http://www.virtualaudiostreaming.net/sdk-license.html
I'm writing a cross-platform program that involves scrolling a waveform along with uncompressed wav/aiff audio playback. Low latency and accuracy are pretty important. What is the best cross-platform audio library for audio playback when synchronizing to an external clock? By that I mean that I would like to be able to write the playback code so it sends events to a listener many times per second that includes the "hearing frame" at the moment of the notification.
That's all I need to do. No recording, no mixing, no 3d audio, nothing. Just playback with the best possible hearing frame notifications available.
Right now I am considering RTAudio and PortAudio, mostly the former since it uses ALSA.
The target platforms, in order of importance, are Mac OSX 10.5/6, Ubuntu 10.11, Windows XP/7.
C/C++ are both fine.
Thanks for your help!
The best performing cross platform library for this is jack. Properly configured, jack on Linux can outperform Windows asio easily (in terms of low latency processing without dropouts). But you cannot expect normal users to use jack (the demon should be started by the user before the app is started, and it can be a bit tricky to set up). If you are making an app specifically for pro-audio I would highly recommend looking in to jack.
Edit:
Portaudio is not as high-performance, but is much simpler for the user (no special configuration should be needed on their end, unlike jack). Most open source cross platform audio programs that I have used use portaudio (much moreso than openal), but unlike jack I have not used it personally. It is callback based, and looks pretty straightforward though.
OpenAL maybe an option for you.