Using Talkman USB Mic for sound recording usin Homebrew APP?

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
Horendus
Posts: 3
Joined: Tue Jan 10, 2006 1:33 pm

Using Talkman USB Mic for sound recording usin Homebrew APP?

Post by Horendus »

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
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....
adrahil
Posts: 274
Joined: Thu Mar 16, 2006 1:55 am

Post by adrahil »

Don't have a usb mic, but the syscalls from usbmic.prx have been pretty much figured out... One would have to run 2.60+ imho.
Horendus
Posts: 3
Joined: Tue Jan 10, 2006 1:33 pm

Post by Horendus »

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?
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....
Fanjita
Posts: 217
Joined: Wed Sep 28, 2005 9:31 am

Post by Fanjita »

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.
Got a v2.0-v2.80 firmware PSP? Download the eLoader here to run homebrew on it!
The PSP Homebrew Database needs you!
adrahil
Posts: 274
Joined: Thu Mar 16, 2006 1:55 am

Post by adrahil »

Indeed, with the analogue you already have the Input syscalls in the 1.5 FW:

http://moonlight.lan.st/1.50/kd/audio.html
imhotep
Posts: 41
Joined: Tue Dec 13, 2005 9:15 pm

Post by imhotep »

why 2.60?the japanese version required only 2.00 to play.i own it.
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

details on the audio input syscalls

Post by lteixeira »

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
User avatar
Saotome
Posts: 182
Joined: Sat Apr 03, 2004 3:45 am

Post by Saotome »

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.
infj
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by lteixeira »

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
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by 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
User avatar
Saotome
Posts: 182
Joined: Sat Apr 03, 2004 3:45 am

Post by Saotome »

Ah, I see, so it was really the missing remote connector. To bad I bought only the headset without remote :(

But good to see that it already works :)
infj
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by 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
User avatar
Saotome
Posts: 182
Joined: Sat Apr 03, 2004 3:45 am

Post by Saotome »

Well actually everything I'm doing is including audio.h,
-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);
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: Select all

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.

P.S.: My program is running in user mode.
infj
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by lteixeira »

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
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by 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
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

PSP Memo Recorder v0.5

Post by lteixeira »

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
wazowski
Posts: 10
Joined: Fri Apr 07, 2006 1:27 am

Post by wazowski »

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.
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by lteixeira »

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
wazowski
Posts: 10
Joined: Fri Apr 07, 2006 1:27 am

Post by wazowski »

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

Code: Select all

typedef void (* pspAudioCallback_t)(void *buf, unsigned int reqn, void *pdata);
and the thread is

Code: Select all

typedef int (* pspAudioThreadfunc_t)(int args, void *argp);
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--
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by lteixeira »

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

Code: Select all

typedef int (* pspAudioThreadfunc_t)(int args, void *argp);
isn't used anywhere in pspaudiolib and I also don't use it.
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 :( )
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).
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.
Correct.
P.D.: lteixeira are you from Galicia?? or other city of Spain??
None of the two :) I'm from Portugal, which is a totally separate contry next to Spain.

Thanks.

lteixeira




[/code]
wazowski
Posts: 10
Joined: Fri Apr 07, 2006 1:27 am

Post by wazowski »

Ok, now I'm looking at the right file ;)
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).
I see, so the thread function is:

Code: Select all

static int AudioChannelThread(int args, void *argp)
and the initialization function is:

Code: Select all

int pspAudioInit()
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.
Grizzly_cf
Posts: 6
Joined: Mon Jul 24, 2006 8:03 pm

Post by Grizzly_cf »

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:
Image

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??
Image
wazowski
Posts: 10
Joined: Fri Apr 07, 2006 1:27 am

Post by wazowski »

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:
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.
I supose gain level is something that will be improve.

p.s. And not, I'm not from Poland :)

thank you
Grizzly_cf
Posts: 6
Joined: Mon Jul 24, 2006 8:03 pm

Post by Grizzly_cf »

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!

Image
Image
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by lteixeira »

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
wazowski
Posts: 10
Joined: Fri Apr 07, 2006 1:27 am

Post by wazowski »

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.
Hello Saotome,
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.
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by lteixeira »

Hi,

I'm contributing the audio input library I've created for the PSP Memo Recorder program I've created. It can be found in this post.

lteixeira
lteixeira
Posts: 14
Joined: Fri Jul 14, 2006 6:22 am
Location: Portugal

Post by lteixeira »

Saotome, do you have a better idea what the arguments of sceAudioInputInit do? We already know the following for sure:

Code: Select all

int sceAudioInputInit(short arg0, short mic_vol, short arg2);
- 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:

Code: Select all

           sceAudioInputInit(0xffff, 0x0010, 0x0000);
then there is no audio input. If you change it to:

Code: Select all

           sceAudioInputInit(0x0000, 0x0010, 0x0000);
- 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
User avatar
Saotome
Posts: 182
Joined: Sat Apr 03, 2004 3:45 am

Post by Saotome »

Sorry I didn't have time to do any further tests with this, too busy with my job atm. Also I didn't get my remote that I ordered yet, so I cannot do tests even if I had time. I gues you're on your own for the moment
infj
wazowski
Posts: 10
Joined: Fri Apr 07, 2006 1:27 am

Post by wazowski »

edited: sorry for the post
Post Reply