John Stirling wrote:
> if milko's not there maybe someone else could answer this ?
> 
> 
> John Stirling wrote:
> 
>> This is now becoming more of an issue for us.
>>
>> I think we want to investigate the 2 player crossfading solution you 
>> mention below.
>>
>> Can you explain this in more detail (correct my explanation below). 
>> Initially we're trying to
>> . play first URL
>> . at some point play another clip (eg alarm) on top of it whilst still 
>> playing the 1st clip with audio muted
>> . when 2nd clip finishes, fade back to original clip
>>
>> // Open URL 1
>> pPlayer1->OpenURL(pszURL)
>> pPlayer1->Begin();
>>
>> // Preload URL 2. queue up audio data but don't start playback
>> pPlayer2->OpenURL(pszURL)
>> pPlayer2-> ??? (what do we call to prebuffer so that it is in a ready 
>> to play state ?)
>>
>> // Switch audio to URL 2
>> ??
>> ??
>>
>> // Switch back to URL 1
>> ??
>> ??
>>
>> Any examples you could give me on this ? Note - we're using cayenne 
>> and ideally don't want to switch to atlas at this stage.
>>
>> John

I think all of us are traveling today. But, real quick, you could
just call Begin() and then Pause() just as the clip gets done
buffering.


You can also check out IHXTrack and IHXPrefetch which is what SMIL
uses to do that kind of stuff.

more later as I have time.....
--greg.


>>
>>
>>
>> Milko Boic wrote:
>>
>>>
>>> Some player designers have opted for using multiple player objects to 
>>> accomplish gap-less playback rather than improve gapless playback 
>>> directly in the core. A new player object is constructed and 
>>> prefetched some amount of time prior to the ending of the current 
>>> player object. New is started (Begin()) precisely at the desired 
>>> point - possibly with some amount of overlap with previous track 
>>> while gradually decreasing the volume of one and increasing the 
>>> volume of the new one (cross-fading).
>>>
>>> Milko
>>>
>>> At 07:39 AM 5/17/2007, John Stirling wrote:
>>>
>>>>>> For our media player feature we maintain our own playlist and pass 
>>>>>> single URLs in to helix once the previous track has completed. The 
>>>>>> user an edit the playlist dynamically while a track is
>>>>>>
>>>>> playing so
>>>>>
>>>>>> we don't know that far in advance what the next track is going to 
>>>>>> be. Is
>>>>>>
>>>>> there
>>>>>
>>>>>> any way for this sort of behaviour to be supported ?
>>>>>>
>>>>>>
>>>>>
>>>>> You can still use the group manager. Only tracks in the current group
>>>>> consume
>>>>> resources (network, file format, renderers, etc.). The tracks in 
>>>>> future
>>>>> or past groups have little more the track URL and a few other
>>>>> properties that persist after that group is played.
>>>>>
>>>>> Potentially, if you were appending additional groups/tracks to
>>>>> the group manager, then your resources would increase slightly
>>>>> over time, but that should be very slight. Also, at some point,
>>>>> you could just restart everything with another IHXPlayer::OpenURL(),
>>>>> and that would clear out the group manager.
>>>>>
>>>>> Also, if you used the group manager, you would get the benefit of
>>>>> the user being able to move *backwards* through a playlist for
>>>>> free. All you would have to do is call 
>>>>> IHXGroupManager::SetCurrentGroup()
>>>>>
>>>> OK thanks. I'll get back to you with more detailed questions on how 
>>>> to do that later.
>>>>
>>>>
>>>>>
>>>>>> Can you also confirm it is totally seamless. ie you don't hear any 
>>>>>> gaps in the audio.
>>>>>>
>>>>>>
>>>>>
>>>>> Just play a .ram file with two or three URLs that you normally 
>>>>> would have set individually and see what the
>>>>> performance is. I don't think it's going to be absolutely
>>>>> NO gap at all, but the gap is going to be very short,
>>>>> assuming that the code that prefetches the next group
>>>>> is working correctly.
>>>>>
>>>> Tried that. It's certainly much improved, but there is still a 
>>>> fraction of a second gap. I can see the 2nd track begin to prebuffer 
>>>> about 3-4 seconds before the 1st one finishes. I expect this would 
>>>> be good enough for most users (I don't think iPods do any better)
>>>>
>>>> We do have a few customers who are pushing for NO gap. Can you 
>>>> confirm that there are no plans for this to developed as part of 
>>>> helix ? Assuming no helix support then could you comment on what 
>>>> might be involved in getting this working.
>>>>
>>>>> Eric
>>>>>
>>>>>
>>>>>
>>>>>> John
>>>>>>
>>>>>>
>>>>>> Henry Ping wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> There is logic in place to handle the feature you describe, it's 
>>>>>>> in client/core/hxplay.cpp, CheckToStartNextGroup().
>>>>>>> The player will try to prefetch the next playgroup when the current
>>>>>>> playgroup has received all the data. Each track in playlist
>>>>>>
>>>>>>
>>>>>> has its own
>>>>>>
>>>>>>
>>>>>>> group:
>>>>>>>
>>>>>>> Track0 -> Group0
>>>>>>> Track1 -> Group1
>>>>>>> ..
>>>>>>>
>>>>>>> Henry
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: helix-client-dev-bounces at helixcommunity.org 
>>>>>>>> [mailto:helix-client-dev-bounces at helixcommunity.org] On Behalf 
>>>>>>>> Of John Stirling
>>>>>>>> Sent: Wednesday, May 16, 2007 1:07 AM Ping
>>>>>>>> To: ehyche at real.com
>>>>>>>> Cc: helix-client-dev at lists.helixcommunity.org
>>>>>>>> Subject: Re: [Helix-client-dev] gapless playback
>>>>>>>>
>>>>>>>> eg If you've got an album where track 1 goes seamlessly into 
>>>>>>>> track 2 we want to be able to play this back with no gaps 
>>>>>>>> between tracks. Currently we play track 1, wait for it to stop, 
>>>>>>>> then start the next track which generally results in a 2-4 
>>>>>>>> second gap between tracks depending on where the content is 
>>>>>>>> stored. So we'd want the 2nd track to be prefbuffered and ready 
>>>>>>>> to output raw audio data as soon as the 1st track finishes.
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>