I have a native audio app already running on a lot of Android hardware. I use JNI to call AudioTrack.getNativeOutputSampleRate to get the native sample rate for the audio pipeline (duh). This is used to initialize OpenSL for audio output.
On the Google Tango device, getNativeOutputSampleRate returns 48khz. But using that rate yields glitchy audio. However, if I initialize the OpenSL player with 44.1 kHz, I get proper audio.
The fact that the code works on a lot of other phones types (and older OSes) makes me think it is the device itself that reports the wrong thing. But, hey, it's probably something I do anyway...
Anybody has an idea?
Related
We have an iOS app that we are currently rebuilding for Android. The app relies on being able to scrub video with frame accuracy. We have 3D animations that are rendered out as single frames; we build subsets of frames into lots of small (1-2 second) videos; and the app provides the ability to scrub those videos and see each individual frame.
The MP4 videos we initially created work fine on iOS. When we tried to get them working on Android (using the MediaPlayer class), we entered a world of pain! What we need to do is find a video format that will play and allow frame-accurate scrubbing across all Android devices, using MediaPlayer.seekTo(). Initially we are targetting Android 3.0 and above, but we probably want to stretch back to 2.3.3 after our initial release. Here's what I've discovered so far:
(A) Android claims that H264 "baseline profile" should be supported everywhere: (URL). However, within that, there are dozens of other settings that may or may not be supported. Is there a more fine-grained list anywhere? Currently we are converting to H264 within an MP4 container.
(B) I haven't yet seen an Android device that will accurately scrub H264 files without inserting keyframes ("intra frames"). iOS will happily take H264 files without keyframes and provide accurate scrubbing. It seems that, to allow accurate scrubbing, we need to insert a keyframe for every frame of the video (the relevant ffmpeg setting is "-g 1"). This significantly increases the file size.
(C) However, inserting a keyframe for every frame results in a video that will not play at all on the Samsung Galaxy Note 3 (Snapdragon chipset I believe). Reducing the keyframes to every second frame or above seems to work (ffmpeg setting "-g 2").
To summarise:
MediaPlayer.seekTo() seems very dependent on the video format, and varies across devices. Is this the intention? Is there a base level of behaviour that seekTo() is supposed to provide, regardless of format?
What video format that will allow frame-accurate scrubbing (using MediaPlayer.seekTo()) across all Android devices (at least for 3.0 and above?)
The MediaPlayer isn't likely to give you what you want anytime in the near future. The underlying native players are still relatively immature in some respects, not to mention H.264 in particular has lost favor at Google (and other places) because of patent issues.
You may want to look into using ffmpeg itself on Android. See here for some help with that. Using ffmpeg on Android isn't uncommon, so there's plenty of info on how to do it floating around.
Making the video all i-frames seems a terrible waste. I would avoid that at all costs if I were you.
3gp works fine for me. However, the video seems to restart a couple of frames before.
I'm building an audio application in Ruby which needs low latency audio playback. So far, I'm using SDL, which is great for a prototype, but it's got nowhere near enough performance for what I need.
I've tried using the ruby-jack gem, but it doesn't seem complete enough to inject any audio into a playback port (and the documentation is wildly incomplete).
If it changes much, I'm on OS X (but I'd like something that's decently cross-platform), and I'm (currently) playing back small WAV files, but more formats would be better. I don't want especially want to call a system application to do this, either.
My application's full source is available on Github; the salient features of it are in a gist, for those who want to have a look.
I'm not too certain if I have the correct answer for you, but I believe it may be worth your time to look into rbSFML. It is a binding for SFML, a multi media library, which has been growing in popularity.
Go here for rbSFML
http://groogy.se/mainsite/rbsfml/
SFML main page
http://www.sfml-dev.org/
Wish I had more information for you!
Can anybody give me a link to a working example of playing background live-streaming audio in Window Phone 7 (or 7.1)? I saw a lot of examples (in microsoft.com too) and noone of them works correctly for playing a background live-streaming audio.
FYI, here's an url of live-streaming audio http://radiozetmp3-02.eurozet.pl:8400/
Background audio is not supported on 7.0, only 7.1 (and above).
If you want to play streaming audio in a format/codec which is not natively supported by the phone you must do it with an AudioStreamingAgent. If it is a supported codec, you can use an AudioPlayerAgent (see sample here).
Using an AudioStreamingAgent is a nontrivial task and requires a deep understanding of the codec you need to play so you can convert it to something the phone understands. I know of one person who did this, for a H.264 stream, and it took a long time and much hair pulling to get it working. And before anyone asks: No, they are not able to share code from that project.
If you really must go down this route, the ManagedMediaHelpers (previously here) are a good place to start, but yes, they don't cover all codecs and this is, potentially, very complicated and not something well documented on the web.
In Windows XP, you can configure your sound card properties via the preloaded windows software. In the recording properties, if "stereo mix" or "wave out" (or something similar) is selected as the recording device, programs that can record audio ("Sound Recorder" in windows for example) record a decent quality wave file of the audio stream. I usually use Goldwave from download.com to do this as an example of a third-party application that functions the same.
Well, I've had trouble getting this scenario to happen on Windows Vista or later in a direct no-bullsh*t manner as described above. It's more than just Vista+, it's also that some sound cards don't have that option at all.
I was just wondering if there is a way to run a windows-friendly program (VB?) that takes your audio output stream and converts it (in realtime, obviously) to a WAV file with the default sampling rate as other WAV files have.
Ideally, it would cool if it worked on any operating system, so is it possible to write a web service that "listens" to your audio card like that without making the computer think it's getting a virus attack or something?
Possibly related question:
How to save web audio streaming to file ( c++ / java )
I'm only aware of one manufacturer of sound cards that enabled that option (Creative). However Vista and beyond support a "loopback" mode which gives you effectively the same functionality. You need to use the low level WASAPI rendering stack but it should work just fine.
https://github.com/rdp/virtual-audio-output-sniffer provides a directshow input device to capture the sum of wave out for vista+
You could use low level waveOut API injection and capture what it receives.
I have SkypeMXrecorder, a software that does just that - inject into any exe and 'sniffs' what's going out from it and into the sound hardware. But, it seems rather complicated to implement...
I'd like to pull a stream of PCM samples from a Mac's line-in or built-in mic and do a little live analysis (the exact nature doesn't pertain to this question, but it could be an FFT every so often, or some basic statistics on the sample levels, or what have you).
What's a good fit for this? Writing an AudioUnit that just passes the sound through and incidentally hands it off somewhere for analysis? Writing a JACK-aware app and figuring out how to get it to play with the JACK server? Ecasound?
This is a cheesy proof-of-concept hobby project, so simplicity of API is the driving factor (followed by reasonable choice of programming language).
The principal framework for audio development in Mac OS X is Core Audio; it's the basis for all audio I/O. There are layers on top of it like Audio Toolbox, Audio Queue Services, QuickTime, and QTKit that you can use if you want a simplified API for common tasks.
To just pull a stream of samples, you'd probably want to use Audio Queue Services; the AudioQueueNewInput function will set up recording of PCM data and pass it to a callback you supply.
On your Mac there's a set of Core Audio examples in /Developer/Examples/CoreAudio/SimpleSDK that includes a use (AQRecord in AudioQueueTools) of the Audio Queue Services recording APIs.
I think portaudio is what you need.
Reading from the mike from a console app is a 10 line C file (see patests in the portaudio distrib).
Apple provides sample code for reading and writing audio data. Additionally there is a lot of good information in the Audio section of the Apple Developer site.