Audio Proxy Server v2.31 released

[mgroeber9110]

Unfortunately that is the status of APS. PCM is not going to be available in APS for N95. PCM has given quite big delay in uplink and it is not sutible for speech applications. The engineering team later has focused only on codecs which high performance.

PCM is till supported in N95 but it can't be mixed with uplink by 3rd party application. The native music player can mix, because the native music player is identified as Nokia Software to the audio layer.

Thanks for looking into this, and keeping us developers up to date.

At the moment, I am a bit puzzled, because I thought the whole point of the APS was to appear as Nokia Software to the audio layer... Do you mean that the delay is to big for interactive VoIP (btw: is it possible to quantify that? 200ms? 1000ms?), but for the music player it is not such a big deal if the music is played slightly later?

Would these restrictions also apply for playing audio to the local user only, rather than into the uplink during a call? There are also some applications (like ours, which is concerned with text-to-speech) where this would be just as useful, and where the acceptable delay is likely much longer than for VoIP.

Are use cases like these taken into account in the design of the APS as well?

[wmseto]

You are correct. If for audio playback, the delay is probably acceptable for most people. I am referring to PCM delay is too big for VoIP, not in the case if music playback. AFAIK, our PCM HW codec uses a 4K buffer, and no way to change it. I am not an audio expert, but I believe that is somewhere close to 200ms.

Playback to local user do not need APS at all, if audio routing is not a requirement, i.e. the default speaker is okay for you. However, you still have the 4K PCM buffer restriction.

Hope this helps.

[wmseto]

kalyanich, your package should have an example. That is the best place to start. Build and run that example. If you need to, expand your application from the example.

Hope this helps!

[wmseto]

rob_savageminds,

The audio adaptation team has advised the uplink mixing of VoIP client and CS client is defined in our product teams (phone program teams). Apparently, in some phones, there are requirements to not mix audio of both clients. (since our example here uses VoIP pref vaule, the apps are considered to be VoIP clients).

At the moment, we don't have a solution to achieve the same behavior (VoIP audio uplink and CS Telephony uplink mix) in the phone that you have observed.

Forum Nokia is actively discussing this requriement for our developers with various teams within Nokia. I encourage any developers who are interested in this functionality offically supported to enter platform requirement (see here for details).

[mgroeber9110]

Playback to local user do not need APS at all, if audio routing is not a requirement, i.e. the default speaker is okay for you. However, you still have the 4K PCM buffer restriction.

My understanding so far has been that you need the APS also for local playback if you want it to happen during a phone call, where the regular audio streaming API (CMdaAudioOutputStream) from non-Nokia apps usually gets muted.

Also, we find that there seem to be other subtle differences in how audio policy works for non-Nokia apps and built-in ones: as an example, at the same priority and preference settings (EMdaPriorityMin and EMdaPriorityPreferenceNone), the playback of ringtone samples in the profile application interrupts speech played through the built-in TTS engine of the phone, while speech streamed through the CMdaAudioOutputStream suppresses ringtone playback.

Is it likely that this behavior is going to be different when playing audio through the APS rather than through CMdaAudioOutputStream?

[rob_savageminds]

<snip>
At the moment, we don't have a solution to achieve the same behavior (VoIP audio uplink and CS Telephony uplink mix) in the phone that you have observed.
<snip>

Thanks for getting the clarification. This is really bad news for us though. It doesn't seem right that the Series 60 platform should behave so differently on different phone models. As a developer this is a nightmare, since we have to pass on this confusing situation to our customers when they ask what phones models they can use.

Our requirement is really nothing to do with voip, just a very simple one shared by many developers on this forum (judging by the number of times people ask for it): ability to mix audio into CS uplink. There are very many use cases apart from Voip - e.g. ability to answer a call and play a greeting, as in on-phone voicemail.

I will register the requirement using the link you provided. Once again thanks for your persistence in getting to the bottom of it!

[tpatja]

Hi,

I can't get the APS SIS to install on a Samsumg i520v phone (S60 3rd ed FP1).
Is the installation restricted to Nokia VIDs ? If so, why ?


teemu

[chico156]

hi, I have changed the "streamer" codes to send voice to uplink via APS 2.31, and it works. But I cann't record the downlink, because both EPlayQueue and ERecordQueue have no downlink voice data.
what can i do?

[wmseto]

Also, we find that there seem to be other subtle differences in how audio policy works for non-Nokia apps and built-in ones: as an example, at the same priority and preference settings (EMdaPriorityMin and EMdaPriorityPreferenceNone), the playback of ringtone samples in the profile application interrupts speech played through the built-in TTS engine of the phone, while speech streamed through the CMdaAudioOutputStream suppresses ringtone playback.

You are correct. The differences of non-Nokia apps vs built-in app is mainly due to Nokia VID check. Each application (exe) can have a VID assign to it. The Audio Policy of Nokia 3rd edition S60 Phones checks this VID value.

[wmseto]

I can't get the APS SIS to install on a Samsumg i520v phone (S60 3rd ed FP1).
Is the installation restricted to Nokia VIDs ? If so, why ?

What error message have you received? If the manufacturer choose to restricted VID on installation, it is possible. However there could be other reasons. Error message will give hints what is the cause.

However, APS is really implemented to give extra audio functionalities on top of Nokia default audio policy at the HW layers. I suspect even we can resolve the installation issue; the HW layers will be quite different from another phone manufacturer. There are a lot of reasons why HW are different of course, i.e. cost, design, technologies...

Can you please tell me more if you have similar audio challenges in Samsumg i520v? i.e. Audio not route to ear-piece, not mix with CS uplink, etc. Therefore you have to use APS... This is the first time I have encounter a this type of audio question on our licensee phones. I really want to report back to our platform, and indicate the importance of the issue.

[wmseto]

But I cann't record the downlink, because both EPlayQueue and ERecordQueue have no downlink voice data.

Are you referring to downlink data from CS call? Actually, you cannot get the downlink data into your application. The downlink data for CS call is route directly to the ear-speaker. In other words, downlink is certainly not mixed with your play queue. Though if you play something through, I think then both end up in the ear-speaker and "sound" like they are mixed.

If you want to record the voice data into a file or buffer, you can use CMdaAudioRecorderUtility. That can capture downlink data I believe.

[tpatja]

What error message have you received? If the manufacturer choose to restricted VID on installation, it is possible. However there could be other reasons. Error message will give hints what is the cause.

I get "certificate error". Could it be that SIS files signed with manufacturer-granted capabilities dont install on S60 lisencee phones ? Or the VID ?

However, APS is really implemented to give extra audio functionalities on top of Nokia default audio policy at the HW layers. I suspect even we can resolve the installation issue; the HW layers will be quite different from another phone manufacturer. There are a lot of reasons why HW are different of course, i.e. cost, design, technologies...

Can you please tell me more if you have similar audio challenges in Samsumg i520v? i.e. Audio not route to ear-piece, not mix with CS uplink, etc. Therefore you have to use APS... This is the first time I have encounter a this type of audio question on our licensee phones. I really want to report back to our platform, and indicate the importance of the issue.

You are correct, other audio routing solutions will not work fully for us. Issues include routing audio between loudspeaker and earpiece and volume control. APS does the job on Nokia devices. Our non-APS version works with limited functionality. If APS would install and work on the Samsung phones, we could provide the full functionality for those as well.


teemu

[wmseto]

If APS would install and work on the Samsung phones, we could provide the full functionality for those as well.

teemu, let me look into the installation part first. I will be pleasantly surprised if ASP works on Samsung phone.

BR

[noleti]

sorry for reviving this thread, I am searching for a solution to play back very short audio sequences with minimal delay - so far I only tried the traditional PCM playback using the Symbian API. Would using the APS with some different encoding help me with this? I read in the release notes about an delay of 30ms, which is at least better than the 200ms I'm seeing at the moment.

Thanks for feedback
Ole

[wmseto]

Would using the APS with some different encoding help me with this?

First of all, APS does not support PCM.

I believe it is fine to use Symbian API directly. The delay of 200ms is actually cause by the large frame size of the PCM. If you swith to AMR or something with a smaller frame size, you can probably see a faster response time.

Hope this helps.