Using Talkman USB Mic for sound recording usin Homebrew APP?
Using Talkman USB Mic for sound recording usin Homebrew APP?
Hey.
I was just wondering...
I am a PSP homebrew user and a musician with some basic programming skills.
To any experience PSP programmers out there...
Would it be possible for me(or anyone else) to write a homebrew app....using C or Lua that uses the Talkman USB mic to do sound recording...to mp3...wav or watever format PSP could encode to?
Im not looking for incredible quaility...just that of a flash memory sound recorder which would have same kinda mic quality as TALKMAN Mic.
Possibly a selectabe bit rate.
This would be perfect for recording our practice sessions.
Also....sumhow using the USB interface to plug in a beter quality mic than that of the talkman mic.
Any help on this topic would be apriated.
Thnx
Jasper
I was just wondering...
I am a PSP homebrew user and a musician with some basic programming skills.
To any experience PSP programmers out there...
Would it be possible for me(or anyone else) to write a homebrew app....using C or Lua that uses the Talkman USB mic to do sound recording...to mp3...wav or watever format PSP could encode to?
Im not looking for incredible quaility...just that of a flash memory sound recorder which would have same kinda mic quality as TALKMAN Mic.
Possibly a selectabe bit rate.
This would be perfect for recording our practice sessions.
Also....sumhow using the USB interface to plug in a beter quality mic than that of the talkman mic.
Any help on this topic would be apriated.
Thnx
Jasper
The PSP is a system of circuts...its has to be hardware hackable....
I would do anything to interigate an Engineer for SONY that helped design the PSP....
I would do anything to interigate an Engineer for SONY that helped design the PSP....
Hmm...having to run 2.6 Firemare would be an issue.
So bascly i could find out the USB sys calls and use them to interact with the mic.
Houw would i go about using the PSP to encode and record to memory stick?
Would i just be able to call a function, encode to MP3 or somting?
So bascly i could find out the USB sys calls and use them to interact with the mic.
Houw would i go about using the PSP to encode and record to memory stick?
Would i just be able to call a function, encode to MP3 or somting?
The PSP is a system of circuts...its has to be hardware hackable....
I would do anything to interigate an Engineer for SONY that helped design the PSP....
I would do anything to interigate an Engineer for SONY that helped design the PSP....
Might be better to use the analogue mic input in the headphone socket, using either the SOCOM headset or a home-made one (there are plenty of how-tos around on making one).
The advantage of using the analogue mic input is that it's more universal - the firmware requirements are lower (v2.0, possibly lower) and it's easier for people to get hold of a suitable mic.
The advantage of using the analogue mic input is that it's more universal - the firmware requirements are lower (v2.0, possibly lower) and it's easier for people to get hold of a suitable mic.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
The PSP Homebrew Database needs you!
Indeed, with the analogue you already have the Input syscalls in the 1.5 FW:
http://moonlight.lan.st/1.50/kd/audio.html
http://moonlight.lan.st/1.50/kd/audio.html
details on the audio input syscalls
Hi, upon tying to play with the audio input syscalls, so far I've been able to obtain the following:
calling sceAudioInputInit supposing the following prototype:
int sceAudioInputInit(int samplecount, int format);
it returns 0. Next, I call sceAudioInputBlocking from a dedicated thread.
The prototype in this case is:
int sceAudioInputBlocking(int vol, void *buf);
calling this function with these arguments doesn't crash the console but nothing interesting seems to happen. Return value is always -2144993270 and buf contents has all bytes zeroed. Still this is not necessarily bad as I only have a remote and headphones attached to the console. In my program I check this information with the psphprm library, which correctly tells that there is no microphone attached. So it's not clear if the firmware/hardware checks this before trying to put the sound hardware capturing sounds from the input and throwing bytes into the buffer. I must validate this once I get the 4 pin jack for making a microphone adaptor. If anyone has a different idea about how to use these syscalls please expose.
lteixeira
calling sceAudioInputInit supposing the following prototype:
int sceAudioInputInit(int samplecount, int format);
it returns 0. Next, I call sceAudioInputBlocking from a dedicated thread.
The prototype in this case is:
int sceAudioInputBlocking(int vol, void *buf);
calling this function with these arguments doesn't crash the console but nothing interesting seems to happen. Return value is always -2144993270 and buf contents has all bytes zeroed. Still this is not necessarily bad as I only have a remote and headphones attached to the console. In my program I check this information with the psphprm library, which correctly tells that there is no microphone attached. So it's not clear if the firmware/hardware checks this before trying to put the sound hardware capturing sounds from the input and throwing bytes into the buffer. I must validate this once I get the 4 pin jack for making a microphone adaptor. If anyone has a different idea about how to use these syscalls please expose.
lteixeira
I also started to do some tests and reverse engineering last week.
I found out that the sceAudioInput functions look like this:
sceAudioInput(length, sample_rate, buffer);
length is in samples, sample_rate is samples per second (44100 for example).
And It seems to work - I get some "noise" as input in the buffer, but not really from the microphone: theres no "reaction" when I speak into the microphone (I have the original Sony PSP headset).
Most likely it's because I'm calling the Init function with the wrong args.
From reverse engineering I found out the args are three shortints (s16) which are stored into a struct when calling the function, but absolutely no idea what the args are.
Another possibility could be that I don't have a remote attached to the headset. But that's rather unlikely i think.
Here's my test program.
I found out that the sceAudioInput functions look like this:
sceAudioInput(length, sample_rate, buffer);
length is in samples, sample_rate is samples per second (44100 for example).
And It seems to work - I get some "noise" as input in the buffer, but not really from the microphone: theres no "reaction" when I speak into the microphone (I have the original Sony PSP headset).
Most likely it's because I'm calling the Init function with the wrong args.
From reverse engineering I found out the args are three shortints (s16) which are stored into a struct when calling the function, but absolutely no idea what the args are.
Another possibility could be that I don't have a remote attached to the headset. But that's rather unlikely i think.
Here's my test program.
infj
Saotome, I tried your program using the remote, and whenever I put and remove the headphones jack there is reaction in the graph so I believe its working. Try using the remote because the 3.5 mm jack in the psp body doesn't have the microphone pins (the connector is a standard 3 pin one). Instead these are located in remote connector. In fact inserting and removing the headphone jack directly on the psp would have no effect on the graph. Anyway I would like to congratulate your nice work, starting from the GUI :)
lteixeira
lteixeira
Moreover I managed to inject some signal and I see a perfectly nice waveform very similar to the picture I see in my oscilloscope :). The second argument of sceAudioInputInit clearly seems to be the microphone gain level. But increasing it's value above 0x20 doesn't have any effect on the amplitude of the signal. Minimum value is represented by a negative value as complement of 2, such that for example 0xfe00 has a smaller gain than 0x0000.
lteixeira
lteixeira
Saotome, are you doing anything else besides initializing the sound input with sceAudioInputInit() (NID = 0x7DE61688) and calling sceAudioInput() (NID = 0x6D4BEC68) to filll the buffer. I'm using 1024 for the buffer size and 44100 as sample rate. I'm calling the function from within a dedicated thread, the same way as it done for the sound output in pspaudiolib, but the buffer is still filled with zeros after calling sceAudioInput. My program is running in kernel mode.
lteixeira
lteixeira
Well actually everything I'm doing is including audio.h,
-lpspaudio in my make file,
and in my main.c :
because they are already in the audio.S of the pspsdk.
Then I call the init: sceAudioInputInit(0, 0x7000, 0); (no special reason for these values, they just work ;))
I noticed that when I call the input function right after the init it doesn't work. Maybe it needs some time to initialize the hardware, thats why you need to press the button to start the input in my demo ;)
When the button is pressed I call the input function every frame:
1024 as length should also work, every value should be ok as long as it's a multiple of 64.
P.S.: My program is running in user mode.
-lpspaudio in my make file,
and in my main.c :
Code: Select all
extern s32 sceAudioInputInit(s32 a0, s32 a1, s32 a2);
extern s32 sceAudioInput(s32 a0, s32 a1, void *a2);
Then I call the init: sceAudioInputInit(0, 0x7000, 0); (no special reason for these values, they just work ;))
I noticed that when I call the input function right after the init it doesn't work. Maybe it needs some time to initialize the hardware, thats why you need to press the button to start the input in my demo ;)
When the button is pressed I call the input function every frame:
Code: Select all
if (recflag & 1) sceAudioInput(0x200, 22050, smpmem);
P.S.: My program is running in user mode.
infj
Ok, now it works. I had to change a few things. I was looking up the syscall pointers using kernel mode code such as sceKernelFindModuleByName(). Now I'm declaring the functions using extern as you said, which makes it a lot simpler :) I didn't notice these where specified in audio.S. Now I can run the code in user mode (I also had to remove all the code referencing kernel mode syscalls).
In my case I'm not explicity imposing a delay between calling sceAudioInputInit and sceAudioInput, perhaps thread creation is giving enough time for the hardware to prepare for recording.
I only have a strange problem that the sceKernelStartThread() function doesn't return, causing control over the application to be lost while the created thread endlessly captures the audio.
lteixeira
In my case I'm not explicity imposing a delay between calling sceAudioInputInit and sceAudioInput, perhaps thread creation is giving enough time for the hardware to prepare for recording.
I only have a strange problem that the sceKernelStartThread() function doesn't return, causing control over the application to be lost while the created thread endlessly captures the audio.
lteixeira
There is a difference in behaviour between sceAudioInput() and sceAudioInputBlocking(). The first one returns immediately (probably returns before the buffer is entirely filled). The second takes some extra time to return, causing noise to be heard (I have a loop between input and output), most likely gaps in the recording. The system becomes more responsive though. Hitting the Home button causes the system screen to be shown, even though the application doesn't successfully exits by pressing Yes (it shuts down the console after a while). With sceAudioInput not even this happens - the audio thread completely takes over the system.
lteixeira
lteixeira
PSP Memo Recorder v0.5
Hi,
I'm posting PSP Memo Recorder v0.5, which is a sample program showing usage of the audio input syscalls. With this program you can record (in RAM) 5 seconds of audio and play it back afterwards.
It requires the PSP remote and a headset such as the one used for the SOCOM game. PC to PSP headset adapters should also work.
By hitting R trigger recording starts. Hitting L plays the recorded content. Hitting X causes the program to enter loop mode, causing the input to be placed directly in the audio output buffer.
It still has a bug the causes the program to crash after a few runs, but it's just a start point to more interesting stuff.
Credits to Saotome for helping figure out the arguments of these syscalls.
lteixeira
PSP_Memo_Recorder
I'm posting PSP Memo Recorder v0.5, which is a sample program showing usage of the audio input syscalls. With this program you can record (in RAM) 5 seconds of audio and play it back afterwards.
It requires the PSP remote and a headset such as the one used for the SOCOM game. PC to PSP headset adapters should also work.
By hitting R trigger recording starts. Hitting L plays the recorded content. Hitting X causes the program to enter loop mode, causing the input to be placed directly in the audio output buffer.
It still has a bug the causes the program to crash after a few runs, but it's just a start point to more interesting stuff.
Credits to Saotome for helping figure out the arguments of these syscalls.
lteixeira
PSP_Memo_Recorder
Hi,
So basically you are doing this ->
1) declaration of functions:
extern s32 sceAudioInputInit(s32 a0, s32 a1, s32 a2);
extern s32 sceAudioInput(s32 a0, s32 a1, void *a2);
2) start audio input:
sceAudioInputInit(0,0x7000,0);
3) and then start recording... in every frame.
if (recflag & 1) sceAudioInput(0x200, 22050, smpmem);
Ok, but, I dont understand "in every frame". How does sceAudioInput works? Does it need a loop (while,etc...) or a callback?
I hope both of you could share your code for EVERYONE, so we can work all together.
Thank you guys.
So basically you are doing this ->
1) declaration of functions:
extern s32 sceAudioInputInit(s32 a0, s32 a1, s32 a2);
extern s32 sceAudioInput(s32 a0, s32 a1, void *a2);
2) start audio input:
sceAudioInputInit(0,0x7000,0);
3) and then start recording... in every frame.
if (recflag & 1) sceAudioInput(0x200, 22050, smpmem);
Ok, but, I dont understand "in every frame". How does sceAudioInput works? Does it need a loop (while,etc...) or a callback?
I hope both of you could share your code for EVERYONE, so we can work all together.
Thank you guys.
The most adequate is to use sceAudioInput in a thread where a callback from your application is invoked, in a similiar way to what is implemented in pspaudiolib. The only major difference is that instead of writing to a buffer you are reading from it. By frame Saotome means each frame of the two frames of a double buffer that is used to store the audio. So everytime the callback is called your application will be presented with different audio data, through a different pointer to the buffer.
I'm planing to share my code, but I first intend to better document it.
lteixeira
I'm planing to share my code, but I first intend to better document it.
lteixeira
Ok, I think I´m starting to understand this. So the steps are...
// Funtion for buffer reading
// Callback thread calling function for buffer reading
// Sets up the callback thread and start it.
And the audio callback that's implemented in pspaudiolib is
and the thread is
Sorry but I can't understand the implementation in pspsudiolib. I´m watching at pspaudiolib.h but I can't understand what you are telling me. (Sorry :( )
So the audio buffer is similar to the screen, it has a double buffer and when you are rading one, the other one is felled with new data... ok, ok.
P.D.: lteixeira are you from Galicia?? or other city of Spain??
Thank you
Waz--
// Funtion for buffer reading
// Callback thread calling function for buffer reading
// Sets up the callback thread and start it.
And the audio callback that's implemented in pspaudiolib is
Code: Select all
typedef void (* pspAudioCallback_t)(void *buf, unsigned int reqn, void *pdata);
Code: Select all
typedef int (* pspAudioThreadfunc_t)(int args, void *argp);
So the audio buffer is similar to the screen, it has a double buffer and when you are rading one, the other one is felled with new data... ok, ok.
P.D.: lteixeira are you from Galicia?? or other city of Spain??
Thank you
Waz--
Ok wazowski, the callback definition which is in pspaudiolib I also used for the audio input (the best thing to do afterwards is to SVN commit this new code to PSPSDK).
The definition
isn't used anywhere in pspaudiolib and I also don't use it.
Thanks.
lteixeira
[/code]
The definition
Code: Select all
typedef int (* pspAudioThreadfunc_t)(int args, void *argp);
The implementation which is in pspaudiolib.c is quite straightforward: you have the thread function which invokes the callback in a while loop to get the buffer filled with data, and invokes the syscall to pass the buffer pointer to the audio hardware. You also have the initialization functions to get the threads created and the selected audio channels reserved. Inversely you have the function that delete the threads and release the reserved audio channels (pspAudioEnd).Sorry but I can't understand the implementation in pspsudiolib. I´m watching at pspaudiolib.h but I can't understand what you are telling me. (Sorry :( )
Correct.So the audio buffer is similar to the screen, it has a double buffer and when you are rading one, the other one is felled with new data... ok, ok.
None of the two :) I'm from Portugal, which is a totally separate contry next to Spain.P.D.: lteixeira are you from Galicia?? or other city of Spain??
Thanks.
lteixeira
[/code]
Ok, now I'm looking at the right file ;)
and the initialization function is:
So I supose that I have to edit the AudioChannelThread function and add there the sceAudioInput function.
I'm sure I'm wrong, but I´m trying to do my best. I hope you can share your code with all of us.
Thank you for your quick answer.
I see, so the thread function is:The implementation which is in pspaudiolib.c is quite straightforward: you have the thread function which invokes the callback in a while loop to get the buffer filled with data, and invokes the syscall to pass the buffer pointer to the audio hardware. You also have the initialization functions to get the threads created and the selected audio channels reserved. Inversely you have the function that delete the threads and release the reserved audio channels (pspAudioEnd).
Code: Select all
static int AudioChannelThread(int args, void *argp)
Code: Select all
int pspAudioInit()
I'm sure I'm wrong, but I´m trying to do my best. I hope you can share your code with all of us.
Thank you for your quick answer.
-
- Posts: 6
- Joined: Mon Jul 24, 2006 8:03 pm
Hi.
I'm very interested of this project. I do some test's witch program PSP Memo Recoreder lteixeira.
For now I done plug-in microphone:
When I speak to mic, PSP dont record this. But when I use fingers to hit mic, that was rec. So it works! But the signal is very weak and when I playback its very silence. Propably it's a hardware problem (need simply external mic booster), or software (maybe there are configs functions). In datasheet of WM8750 there is a block diagram where is a mic input and mic booster. Maybe to gain a mic signal we need communicacte per i2c witch WM8750. More about Microphone control bias at page 20. (if You may lteixeira please modify your program and add control mic signal strenght.)
btw. The sound lagging in playback. I guss it is programming problem.
Thanks you guys for impressive work.
Sorry for my english I know is very weak :(
p.s. Wazowski do you come from Poland??
I'm very interested of this project. I do some test's witch program PSP Memo Recoreder lteixeira.
For now I done plug-in microphone:
When I speak to mic, PSP dont record this. But when I use fingers to hit mic, that was rec. So it works! But the signal is very weak and when I playback its very silence. Propably it's a hardware problem (need simply external mic booster), or software (maybe there are configs functions). In datasheet of WM8750 there is a block diagram where is a mic input and mic booster. Maybe to gain a mic signal we need communicacte per i2c witch WM8750. More about Microphone control bias at page 20. (if You may lteixeira please modify your program and add control mic signal strenght.)
btw. The sound lagging in playback. I guss it is programming problem.
Thanks you guys for impressive work.
Sorry for my english I know is very weak :(
p.s. Wazowski do you come from Poland??
Hi Grizzly_cf,
Ihave tried the MemoREcorder app. and it works fine. I´m using the remote adaptor and the socom headphone adaptor. And everything I said is recorder and then is played back. It works great with this adaptor configuration. Are you using what lteixeira has said? (this two adaptors)
Here lteixeira talks about gain:
p.s. And not, I'm not from Poland :)
thank you
Ihave tried the MemoREcorder app. and it works fine. I´m using the remote adaptor and the socom headphone adaptor. And everything I said is recorder and then is played back. It works great with this adaptor configuration. Are you using what lteixeira has said? (this two adaptors)
Here lteixeira talks about gain:
I supose gain level is something that will be improve.Moreover I managed to inject some signal and I see a perfectly nice waveform very similar to the picture I see in my oscilloscope :). The second argument of sceAudioInputInit clearly seems to be the microphone gain level. But increasing it's value above 0x20 doesn't have any effect on the amplitude of the signal. Minimum value is represented by a negative value as complement of 2, such that for example 0xfe00 has a smaller gain than 0x0000.
p.s. And not, I'm not from Poland :)
thank you
-
- Posts: 6
- Joined: Mon Jul 24, 2006 8:03 pm
Ok. I will make this.
Or just solder some mini-mic in remote pilot pcb.
edit: I just solder mic to the remote pilot and works good, but sound are still deformed, like a lagging.
lteixeira did you find a problem with few records crash?? It is posible to stream sound signal to files??
Thanks for advice!
Or just solder some mini-mic in remote pilot pcb.
edit: I just solder mic to the remote pilot and works good, but sound are still deformed, like a lagging.
lteixeira did you find a problem with few records crash?? It is posible to stream sound signal to files??
Thanks for advice!
Hi, please check this thread, where I am posting new versions. The latest version already features 60 seconds max recording duration (file recording under way) and you can also control mic gain through the up and down arrows.
lteixeira
lteixeira
Hello Saotome,Well actually everything I'm doing is including audio.h,
-lpspaudio in my make file,
and in my main.c :
Code:
extern s32 sceAudioInputInit(s32 a0, s32 a1, s32 a2);
extern s32 sceAudioInput(s32 a0, s32 a1, void *a2);
because they are already in the audio.S of the pspsdk.
Then I call the init: sceAudioInputInit(0, 0x7000, 0); (no special reason for these values, they just work ;))
I noticed that when I call the input function right after the init it doesn't work. Maybe it needs some time to initialize the hardware, thats why you need to press the button to start the input in my demo ;)
When the button is pressed I call the input function every frame:
Code:
if (recflag & 1) sceAudioInput(0x200, 22050, smpmem);
1024 as length should also work, every value should be ok as long as it's a multiple of 64.
I have a doubt, when you call sceAudioInput, you are calling it from the audio Callback, I mean, both function sceAudioOutput and sceAudioInput are called from the same callbak?
Thank you. I hope you could help me to make this work. Thank you again.
Saotome, do you have a better idea what the arguments of sceAudioInputInit do? We already know the following for sure:
- where mic_vol is simply a signed short representing input volume.
- arg0 produces weird results. In your program I've checked the following:
- when you call sceAudioInputInit for the first time this way:
then there is no audio input. If you change it to:
- it works normally.
- If you call sceAudioInputInit a second time with the first set of arguments, it also works normally.
- playing with arg2 I haven't found any behaviour.
Conclusion: the results are not consistent. Calling the function more than once should have exactly the same result. Can the first argument be a pointer to a buffer or some data structure? Can there be an audio input teardown syscall we don't know?
One upsetting thing I'm noticing is that once the audio input is initialized most of the memory space is allocated, leaving no much room for other stuff. Perhaps these unknown arguments have something to do with it...
lteixeira
Code: Select all
int sceAudioInputInit(short arg0, short mic_vol, short arg2);
- arg0 produces weird results. In your program I've checked the following:
- when you call sceAudioInputInit for the first time this way:
Code: Select all
sceAudioInputInit(0xffff, 0x0010, 0x0000);
Code: Select all
sceAudioInputInit(0x0000, 0x0010, 0x0000);
- If you call sceAudioInputInit a second time with the first set of arguments, it also works normally.
- playing with arg2 I haven't found any behaviour.
Conclusion: the results are not consistent. Calling the function more than once should have exactly the same result. Can the first argument be a pointer to a buffer or some data structure? Can there be an audio input teardown syscall we don't know?
One upsetting thing I'm noticing is that once the audio input is initialized most of the memory space is allocated, leaving no much room for other stuff. Perhaps these unknown arguments have something to do with it...
lteixeira