Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Found a strange behavior while using mme_play_resume_msid( ) for resuming playback on 1st Gen iTouch: (3 Items)
   
Found a strange behavior while using mme_play_resume_msid( ) for resuming playback on 1st Gen iTouch  
Hi,

Just found a strange behavior while using mme_play_resume_msid( ) (An API
function of Aviage Multimedia Suite) for resuming playback on 1st Gen iTouch (in Firmware 1.1.5 or below). The
scenario is as follows:
In most cases, the iTouch can only be successfully resumed playback in the
first time and failed after that. For example, after successfully resumed
playback by using mme_play_resume_msid( ), if disconnect the iTouch and
re-connect it to the accessory, it will failed to resume playback and will
receive MME_PLAY_ERROR_NOTSPECIFIED and MME_EVENT_FINISHED_WITH_ERROR MME
events. The worse thing is, the functionality of the iTouch is also
affected after the error occurs. Once failed to resume playback, if
disconnect the iTouch,  the attempting track on the iTouch can not be
toggled pause and play in Now Playing menu. It looked like something wrong
with iTouch for playing the now playing track and have to go to other menu
to select another track to play, then the iTouch has full functionality
again.
Have tried some other iPods like Nano, Classic and 3G iPhone, seems the
odd behavior only happens on iTouch (1st generation, model MA627ZP,
firmware 1.1.5 or below). 

BTW, we are currently using the latest Aviage MME 1.2 Alpha release (build
20.14)

How To Reproduce: 

1) Select a track to play on iTouch.
2) Connect the iTouch to accessory which running Aviage Multimedia Suite.
3) By using  mme_play_resume_msid( ) API function, the current playing
track on iTouch can be resumed playing successfully.
4) Disconnected the iTouch from the accessory.
5) Re-start the Aviage Multimedia Suite (The purpose of that is just make
sure the issue is not caused by some data bases or track sessions
conflict.)
6) Reconnected the iTouch to the accessory again, most of cases will fail
to resume playback on this kind of iPod and will receive
MME_PLAY_ERROR_NOTSPECIFIED and MME_EVENT_FINISHED_WITH_ERROR MME events.

It looks like this is an iPod issue, but still looking forward the confirm or other info about this. Furthermore, post 
it here maybe can help to complement the iPod compatibility list for the formal Avaige Multimedia Suite release.

Regards,
Chris
Re: Found a strange behavior while using mme_play_resume_msid( ) for resuming playback on 1st Gen iTouch  
On Tue, 12 May 2009, Chris Li wrote:

>Hi,
>
>Just found a strange behavior while using mme_play_resume_msid( ) (An API
>function of Aviage Multimedia Suite) for resuming playback on 1st Gen
>iTouch (in Firmware 1.1.5 or below). The scenario is as follows: In most
>cases, the iTouch can only be successfully resumed playback in the first
>time and failed after that. For example, after successfully resumed
>playback by using mme_play_resume_msid( ), if disconnect the iTouch and
>re-connect it to the accessory, it will failed to resume playback and will
>receive MME_PLAY_ERROR_NOTSPECIFIED and MME_EVENT_FINISHED_WITH_ERROR MME
>events. The worse thing is, the functionality of the iTouch is also
>affected after the error occurs. Once failed to resume playback, if
>disconnect the iTouch, the attempting track on the iTouch can not be
>toggled pause and play in Now Playing menu. It looked like something wrong
>with iTouch for playing the now playing track and have to go to other menu
>to select another track to play, then the iTouch has full functionality
>again.
>Have tried some other iPods like Nano, Classic and 3G iPhone, seems the
>odd behavior only happens on iTouch (1st generation, model MA627ZP,
>firmware 1.1.5 or below).
>
>BTW, we are currently using the latest Aviage MME 1.2 Alpha release (build
>20.14)

Are you able to check the sampling rate on the track that you're trying to
resume? We have found and corrected an issue where if you were trying to
resume playback of a track that was not sampled at 44.1 then it may not
work. (PR 67830)

We've also come across a few issues with playback and behaviour using
itouches with the 1.x stream of firmware that we haven't been able to
reproduce on itouches using the 2.x stream of firmware. These issues are
still under investigation.

Thanks for the detailed method for reproducing the issue. I'll see if I can
confirm similar behaviour here.

Peter

>
>How To Reproduce:
>
>1) Select a track to play on iTouch.
>2) Connect the iTouch to accessory which running Aviage Multimedia Suite.
>3) By using  mme_play_resume_msid( ) API function, the current playing
>track on iTouch can be resumed playing successfully.
>4) Disconnected the iTouch from the accessory.
>5) Re-start the Aviage Multimedia Suite (The purpose of that is just make
>sure the issue is not caused by some data bases or track sessions
>conflict.)
>6) Reconnected the iTouch to the accessory again, most of cases will fail
>to resume playback on this kind of iPod and will receive
>MME_PLAY_ERROR_NOTSPECIFIED and MME_EVENT_FINISHED_WITH_ERROR MME events.
>
>It looks like this is an iPod issue, but still looking forward the confirm or other info about this. Furthermore, post 
it here maybe can help to complement the iPod compatibility list for the formal Avaige Multimedia Suite release.
>
>Regards,
>Chris
>
>_______________________________________________
>General
>http://community.qnx.com/sf/go/post29324
>
>
Re: Found a strange behavior while using mme_play_resume_msid( ) for resuming playback on 1st Gen iTouch  
I think the sampling rate of the track I tried to resume playing back on 1st Gen iTouch should be 44.1khz, I got this 
info from iTune which used for synchronizing the iPod but could not confirm that on run time because seems no way to get
 an sampling rate info for the current playing track on iPod by Aviage APIs or mmecli command. 

I trying using mmecli audio_get_status, however, it just returns an invalid information as follows. It seems this 
command doesn't work for iPods.
mmecli audio_get_status 
(rc=0,errno=0) Codex , bitrate 0, samplerate 0, channels 0, bitrate_type 0, channel_type 0.  Execution Time=0.000.