Hi,

I am looking into the new ability to redirect audio in from a port and to redirect audio out to a port.

This ability is restricted to a 16 kHz sampling rate (at least in the current version).

In my case I need to record audio coming in from the other party. If I redirect the audio to a port, then read the 16kHz PCM data off the port (in order to record it), I also need to pass the PCM data out to the speaker (i.e. the default audio out device) myself (otherwise the user hears nothing).

My question is: has anyone considered the impact on call quality? The user will now hear 16kHz sound instead of 48 kHz sound. Will this be noticeable, or is the audio quality coming in not of sufficient quality in the first place for this to be noticeable?

I presume 16kHz was chosen so as to provide adequate throughput over the port, which is understandable - just need someone to make me feel comfortable that I am not reducing call quality by using this facility to implement recording.

(P.S. the same applies for recording audio coming in through the mic - this is 16kHz also, so the same kind of question applies).

Regards,
Paul

Hi Paul,

We did some research into this matter. As Skype uses 16kHz, this is what is put to the API. We asked for resampling options (like to set kHz rates), but this is unfortunately something the 3rd party application will have to do.

The testing we did resulted in a good quality audio file. We will add a resampling module so that we can input and output to various formats.

Ping me if you have any further questions.

Cheers!

DickS

Hey,

I'm currently having some problems with using the audio API...

I've got skype to record to a wav file, which i've had no problems with. Used the following command:
ALTER CALL 175 SET_OUTPUT file="C:\caller_319.wav",port="1234"

Now i've got a wav file, which I want to play to the person on the other end of the conversation...
If I play that same wav file into skype, I get this:
RESPONSE: ALTER CALL 182 SET_INPUT file="C:\caller_319.wav" port="1234"
RESPONSE: CALL 182 DURATION 7
RESPONSE: CALL 182 DURATION 8
RESPONSE: CALL 182 DURATION 9
RESPONSE: CALL 182 DURATION 10
RESPONSE: CALL 182 DURATION 11
RESPONSE: CALL 182 VAA_INPUT_STATUS FALSE

It plays the entire file, and all is hunky dory

However, if I take another wav file and play it through, I get this:
RESPONSE: ALTER CALL 190 SET_INPUT file="C:\testfile.wav" port="1234"
RESPONSE: CALL 190 DURATION 5
RESPONSE: CALL 190 VAA_INPUT_STATUS FALSE

It fails to play the file

Now I did some research and discovered that all audio must be raw PCM, 16khz, 16bit and mono. Ensuring that I had saved the audio in this format using sony sound forge 7, I tried again. It failed to play.

It's basically refusing to play any files I have created, and will only play files Skype has created itself.

Here are the properties of testfile.wav:

Sample rate: 16,000
Bit depth: 16bit
Channels: Mono
Source: 16,000 Hz, 16 Bit, Mono
Process/DSP: 16,000 Hz, 64 Bit (IEEE Float), Mono
Playback: 16,000 Hz, 16 Bit, Mono
Sample value: 936
Sound data size: 0.31MB (315,520 bytes)

From what I can tell, these properties (apart from the file size) are identical to that of caller_319.wav.

Anyone got any ideas?

Hi,

For your information, in Pamela 3.0 we added remote control for call recording. This means that you can use Pamela to record Skype calls and dont have to mess with all the resampling for playing or writing to a file.

The syntax is:

Pamela.exe /recordingStart (Start call recording remotely)
Pamela.exe /recordingStop (Stop call recording remotely)

By parsing the settings.xml file of Pamela you are able to remote control the options like path to recordings, sampling and bitrates, etc.

I'm seeing the same problem with 16kHz/16bit/mono files exported from Audacity.

(edit)
When SET_INPUT using a file recorded from Skype I see VAA_INPUT_STATUS TRUE. Any other files don't trigger VAA_INPUT_STATUS change.

What Skype version are you using? Are the files PCM-WAV (raw format)?

Skype 2.6.0.97

I tried RAW format (headerless) without success. I also tried various other formats.

I looked at the files saved from Skype SET_OUTPUT using a hex editor. They have a "RIFF WAVEfmt" header like a Microsoft Signed 16bit PCM file. This is the same as my 16kHz, 16bit, 1channel files so I can't understand why they don't work.

I figured out how to make them work. The files saved by skype have a 2 byte null extra format string just before the data statement. I was able to open a file that I created in Audition that didn't have this padding in a hex editor and add it and the file played fine. Be sure to adjust fmt chunk size up by 2 (16 + extra format bytes, so 18 <12 in hex>) as well as the file sizes. See http://www.sonicspot.com/guide/wavefiles.html for details on the WAV format.

Yes, the data is sent in 2KB packages from the Skype API

Thanks. I've tested this and it's working for me.
I've referenced your post in this bug report.




Is this the reason for the extra bytes in the Skype output files?

I have just received a comment from one of our developers who said that they have fixed some problems in reading the WAV header and the fix will hopefully go live with the next hotfix for 2.6

Thank you all for your comments and please update this issue again, once you can check with the next version of 2.6

I was just going to post that we had reported this issue to Skype last week. The extra bytes sent are not supposed to be.

Looking forward to the fix.

Hey everybody,

Sorry about the dealy with the reply. This problem should be fixed in the current 2.6 Beta version .105 which can be downloaded from here - http://skype.com/download/skype/windows/skype26beta.html

If you can reproduce the problem, please report that in the correct Jira issue - https://developer.skype.com/jira/browse/SPA-150

Regards,
Mirje