Oh yeah, I forgot to mention that I have made the blackberry admit that I am trying to record. That has been happening for quite some time. So when you select "record test", the operating system pops up with "application talkLock is attempting to record audio to memory" with an ok/cancel selection or somesuch. Then the application immediately goes back to the main screen, but it is locked up at that point, and the application has to be escaped.
I appreciated that it admitted that I was trying to record, but the amusement from that milestone has worn off.
Upward.
Thursday, April 17, 2008
more strategery
Well I am still not having any fortune with recording audio. My blackberry comes with an application that does what I'm trying to do (at this point), which is record some audio and play it back. It has a very cool interface, it's called "voice notes".
That got me thinking that I might be able to do some trickery to find out how they are recording audio. However a quick search did not allow me to find a way to get the application onto my computer easily. So I found a third party application that does the same thing, and they distribute a build for the blackberry. So I downloaded the .cod file and started beating on it with hammers and screwdrivers and crowbars in the typical UNIX way. I was able to feed it to unzip, which apparently removed the compression. Then I tried to feed it to the jad java decompiler, but it wasn't recognizable as a class file. After talking about this during a smoke break, it occurred to me to run strings on it. strings found stuff of course. Then I thought, what do I really need from this thing? If I at least have the URL that is used when create-ing the "player" to record audio, that is a great clue as to what will actually work. So I just ran strings and grepped for "capture", et voila :) I found the URL.
That still isn't working. I was assuming that I could use Alerts as debugging output, but that doesn't seem to be working as I thought. So I think that I will have to update the Display with text that tells me what part of the code that the application is in while it's running. At least that should give me some more insight as to what is actually happening on the phone. Also I think I will put in a check to get sizeof when recording, so that I can get verification that recording is actually happening.
Stupid amount of work to get something working that is supposed to work according to the API, according to both Sun and RIM. But stupid is okay, I'm used to stupid :/
Shame that the emulator doesn't help; the MMAPI stuff is not implemented in the emulator, so it just gives a nice big stack trace at the recording part of the code.
Onward.
That got me thinking that I might be able to do some trickery to find out how they are recording audio. However a quick search did not allow me to find a way to get the application onto my computer easily. So I found a third party application that does the same thing, and they distribute a build for the blackberry. So I downloaded the .cod file and started beating on it with hammers and screwdrivers and crowbars in the typical UNIX way. I was able to feed it to unzip, which apparently removed the compression. Then I tried to feed it to the jad java decompiler, but it wasn't recognizable as a class file. After talking about this during a smoke break, it occurred to me to run strings on it. strings found stuff of course. Then I thought, what do I really need from this thing? If I at least have the URL that is used when create-ing the "player" to record audio, that is a great clue as to what will actually work. So I just ran strings and grepped for "capture", et voila :) I found the URL.
That still isn't working. I was assuming that I could use Alerts as debugging output, but that doesn't seem to be working as I thought. So I think that I will have to update the Display with text that tells me what part of the code that the application is in while it's running. At least that should give me some more insight as to what is actually happening on the phone. Also I think I will put in a check to get sizeof when recording, so that I can get verification that recording is actually happening.
Stupid amount of work to get something working that is supposed to work according to the API, according to both Sun and RIM. But stupid is okay, I'm used to stupid :/
Shame that the emulator doesn't help; the MMAPI stuff is not implemented in the emulator, so it just gives a nice big stack trace at the recording part of the code.
Onward.
Tuesday, April 8, 2008
another lead
The Blackberry dev kit includes library documentation, so I followed that, but with no improvement. However, last night I did find some code that claimed to record audio on a blackberry. Playback will be the next issue, but first I have to try that new code...
Sunday, April 6, 2008
getting tough
Well, while recovering from the Lurgy, I found myself feeling good enough one day to try to write an application to just record audio to an object in memory, and then play it back. I got tangled up in the user interface part, I was a little feverish and demented. Anyway at some point I ran it on my phone, the application froze and had to be escaped, and I took another round of meds and watched a movie or something.
Then later when I felt better, I just added the functionality from that program into my real "talkLock" program, by adding an option to the main menu called "record test". I also put some Alert(s) into the code to use as debugging statements. MMAPI code doesn't work in the emulators, so you have to test on the phone. The phone doesn't have stdout and doesn't handle the exception methods, so the best you can do is put an alert in that tells you where you are in the code.
Unfortunately none of my alerts are happening (!?). Basically when you select "record test", you get dumped back to the main application display. Finally I tried experimenting with some recording formats, and "amr" encoding made something new happen: the phone prompts me and says "talkLock is trying to record to memory" with a confirmation window. I allow it, and my application displays the main screen and hangs, and there was much rejoicing.
I also found out that J2ME gets unhappy dealing with large hunks of data, so I cut my recording object size down from 700k to 127k, which may have helped me get farther. I have no idea how to proceed at this point.
I downloaded the blackberry development kit, I guess I will try their propietary stuff and see if I can get anywhere with that. Wish me luck, and if you're in the midwest, hope you get into spring without catching the lurgy, or the crud, or whatever you call it :)
Then later when I felt better, I just added the functionality from that program into my real "talkLock" program, by adding an option to the main menu called "record test". I also put some Alert(s) into the code to use as debugging statements. MMAPI code doesn't work in the emulators, so you have to test on the phone. The phone doesn't have stdout and doesn't handle the exception methods, so the best you can do is put an alert in that tells you where you are in the code.
Unfortunately none of my alerts are happening (!?). Basically when you select "record test", you get dumped back to the main application display. Finally I tried experimenting with some recording formats, and "amr" encoding made something new happen: the phone prompts me and says "talkLock is trying to record to memory" with a confirmation window. I allow it, and my application displays the main screen and hangs, and there was much rejoicing.
I also found out that J2ME gets unhappy dealing with large hunks of data, so I cut my recording object size down from 700k to 127k, which may have helped me get farther. I have no idea how to proceed at this point.
I downloaded the blackberry development kit, I guess I will try their propietary stuff and see if I can get anywhere with that. Wish me luck, and if you're in the midwest, hope you get into spring without catching the lurgy, or the crud, or whatever you call it :)
Subscribe to:
Posts (Atom)
