#audiorecord

[redvelvetgirl07031995]

Today's session at the recording studio~~ #recordstudio #audiowork #voiceover #vo #acting #actress #audiorecord

[artbytatianaz]

Audio Cassette Vintage Magnet Tape Record Svema Magnetophone USSR 1980s Ukraine 1990s #Etsy #vintage #Audio #Cassette #instavintage #etsyvintage #Vintageaudiotape #MagnetTape #audioRecord #Svema #Magnetophone #madeinUSSR #1980s #vintageremembrance #etsyshop #Etsyseller #madeinUkraine #1990s https://buff.ly/2FYVZGn

[theeclipseprojectrecords-blog]

(via https://www.youtube.com/watch?v=93KOE-fn9iE)

[seonhooh]

Android Audio Recording

AudioRecord Example

Audio Record Statically

주의사항

레코딩이 다른 작업과 동시에 진행될 때, 레코딩 작업이 지연될 수 있으므로 해당 thread의 우선순위를 조절해야 한다.

참고

AudioRecord API

Thread API

Process API

[intervigil]

Of Phones and Problems

Currently on MicDroid there are certain phones which just do not work properly, (you know who you are... Samsung Galaxy S!) which is quite irritating. Aside from the fact that they cause my app not to work, it's horribly irritating since it means I probably have to go and find a real phone to test on. The fact that I'm currently an unemployed student aside, $500 for a new phone is just plain expensive! 

In any case, this week I received an interesting email from the Peter Kirn of the pd for Android project. Running MicDroid on the newly released Droid X also seems to have had audio problems, specifically crackling and static in the audio stream. According to Peter Brinkmann of the Pd for Android project, this is caused by the call to AudioRecord.read(byte[], int, int) blocking (!) on the Droid X. His workaround is basically to run calls to the the AudioRecord.read function in a separate thread, and use a second buffer, swapping every other read. From this thread, the rest of the program can then poll() the thread's queue for sound data. Oddly enough it doesn't appear that the Nexus One or any of the other previous phones I've tested on suffer from this particular blocking issue. This is going to be a real problem later on, since there appears to be no requirement that all phones must support recording at a certain sample rate and format. Even worse is the problem which the Droid X presents. There is NO guarantee that any of the calls in the API will function the same way on all phones, which can lead to phone-specific hacks and workarounds, and generally unmaintainable code. It also requires developers to either query a database of some sort containing phone-specific workarounds (doesn't exist!), or have to buy the phones and figure it out themselves. (expensive!) At $500 a pop, this might be just the thing phone manufacturers want, but for the small time developer, it adds quite a lot to the cost of development.

This all brings me back to the problem the Galaxy S exhibits. I've read the logs from quite a few models, and it appears there's a buffer overrun somewhere internally. Unfortunately I don't have any clues as to what causes this overrun. My best guess currently is that some of the recording settings are not set properly, despite the phone telling me it is. It's a shame I cannot seem to find Galaxy S recording specs (sample rate, PCM format, etc) supported.

Did I mention that new phones are expensive?

[intervigil]

Asking Android Nicely to Record Audio

Since there are so many Android devices, (yes, fragmentation again!) each supporting different sample rates, channels, formats, there has to be a nice way to figure out what sort of settings your app needs to set on each phone. Unfortunately there is no call that just says, "give me what settings you support". Instead, there is actually a call that will let you query (sort of) your phone to ask it if it supports a certain setup. This is the AudioRecord.getMinBufferSize(int sampleRateInHz, int channelConfig, int audioFormat) function. It will return ERROR_BAD_VALUE if the settings you gave it are not supported. 

From this function, you can construct a wrapper which will go down the list of sample rates (48000, 44100, 22050, 11025, 8000, since annoyingly, Android does not enumerate them for you), until you find the first valid setting, then do the same for channels and PCM formats. MicDroid uses this code to do it.

https://gist.github.com/593200

Since I am only feeding mono input in 16-bit PCM LE format, I have left those as constants in MicDroid, but for more flexibility it is probably better to have a function that will query all possible combinations until it finds one that works, since hardware can be weird. 

Finally, it is important to note that despite the hardware telling your app that it supports a certain combination, it is possible that it actually may not. I am only speculating here, since I have no way to prove my theories (maybe it's magnets) but perhaps this is where the Samsung Galaxy S is causing MicDroid to fail. 

[intervigil]

Live from the Galaxy S, it's an update!

Thanks to the work of Palindrom25 from xda-developers, MicDroid now works on Galaxy S phones. Like I discussed earlier, the Galaxy S, for whatever reason does not seem to report valid recording settings correctly. In order to get it to work properly, it needs a much larger buffer size (on the order of 8x to 16x the size) than it actually requests from AudioRecord.getMinBufferSize. I've solved this in MicDroid by adding a user configurable buffer multiplier option to the preferences. MicDroid will initially try to autodetect this in a very similar manner to my previous post. As always, check out the source code from my repository on GitHub. Hopefully this is of some use to other developers, as I've gotten reports of a few other apps that have similar Galaxy S recording problems.

[intervigil]

Samsung Galaxy S Redux

I've recently been bitten (again) by Samsung Galaxy S AudioRecord bugs, and after having to ignore it to focus on classwork for the past few weeks, it's time to get back into it. The last MicDroid update featured improved error handling due to proper (sort of) use of exceptions instead of an Android Handler to route all exceptions to error handling code. Unfortunately this broke Galaxy S support due to what I believe is described in these posts. It appears the Galaxy S phone just locks up the AudioRecord if you try AudioRecord.startRecording() while it is initialized improperly. This behavior certainly seems consistent with the (mass of) bug reports I've been getting from users. I think I'm going to have to try some of the dirty hacks mentioned above to fix it.

Another project which appears not to have had too many issues with the Galaxy S series is the rather famous Sipdroid. They also have AudioRecord code which supposedly works on the Galaxy S series. They use an interesting method of delaying until the next frame is read before reading from AudioRecord again. I'm fully intending to try this method out also, since if it works, it means I can potentially simplify a lot of the complex recording code current around. Also, it could potentially mean fixing the horrible buffer size hacks I'm using right now and finally allow the Galaxy S series to take advantage of live recording.

Should I get it to actually work, I definitely plan on releasing details.

Finally, the last, best hope for the Galaxy S series is the upcoming release of an official 2.2 ROM. There have been rumors that the 2.2 ROM fixes a lot of the audio bugs that plague the 2.1 Galaxy S ROM, and should an update that fixes these fully roll out, all of these horrible Galaxy S problems should be solved. Obviously this is the best solution for everyone :)

Something else I've been throwing around in my head has been the fact that the Galaxy S has a relatively slow internal SD card. I'm wondering if this has any effect on recording, especially if AudioRecord.read() reads audio at a rate faster than the phone can write. 

It's problems like these that really have me looking forward to Gingerbread, as it's OpenSL and effects pipeline support can potentially go a LONG way towards resolving basic audio functionality issues like these. Now if only we could get Google to release the source code and Samsung to follow standards and release fully baked hardware...