• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: TimeStamp passed to RenderProc when using MusicPlayer
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: TimeStamp passed to RenderProc when using MusicPlayer


  • Subject: Re: TimeStamp passed to RenderProc when using MusicPlayer
  • From: Philippe Wicker <email@hidden>
  • Date: Thu, 17 Apr 2003 08:12:21 +0200

On Thursday, April 17, 2003, at 03:58 AM, Bill Stewart wrote:

Hello,

I should have asked a more specific question. I want to mix midi and audio tracks and manage those tracks with the MusicPlayer. As a result of a recent discussion about the need of a MusicPlayer callback, I've decided to encapsulate the audio file reader in a dedicated AU and to attach this AU to the track using MusicTrackSetDestNode. Now my problem is to choose the better way to indicate to this AU what is the sample "slice" to output at each call of the RenderProc, in particular when the MusicPlayer is looping. To be more specific, I want the loop locators to be modifiable in real time (while playing). I can use "time" API to tell the MusicPlayer/MusicTracks how to loop on one hand, and some parameters to tell the file reader AU what are the loop left and right samples. To avoid race conditions which can occur when loop is enabled or disabled when current sequence position is near the right locator, I need to synchronize the changes. A convenient - and simple - way would have been the sample time if it had reflected the loop state. Looks like I have to find another solution :-(

Nope...

You can't make any of these assumptions.

The sample count just increments and in fact it would be really bad if you tried to decrement it - if you want to loop, etc, then use either the loop properties on the MusicTrack objects or the SetTime call on the MusicPlayer

Bill

On Monday, April 14, 2003, at 10:17 PM, Philippe Wicker wrote:

Hi the list,

I'm wondering what is the expected behavior of the MusicPlayer concerning the AudioTimeStamp value passed to AUs in the target AUGraoh. In a recent thread, it has been said that 'mSampleTime' field will allways be meaningful (from the HAL point of view). Can we assume that this field starts from 0 when the MusicPlayer starts playing? Can we assume that this field will reflects loop state (if L is the sample time at left locator point, and R the sample time at right locator point, then this field will periodically increase from L to R, "drawing" a saw tooth curve)?

Thanks,

Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.


-- mailto:email@hidden
tel: +1 408 974 4056

_______________________________________________________________________ ___
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
_______________________________________________________________________ ___


Philippe Wicker
email@hidden
_______________________________________________
coreaudio-api mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/coreaudio-api
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • CoreAudio and JDK 1.4
      • From: Denis Queffeulou <email@hidden>
References: 
 >Re: TimeStamp passed to RenderProc when using MusicPlayer (From: Bill Stewart <email@hidden>)

  • Prev by Date: Re: 'Ganged' or 'Linked' Hardware
  • Next by Date: CoreAudio and JDK 1.4
  • Previous by thread: Re: TimeStamp passed to RenderProc when using MusicPlayer
  • Next by thread: CoreAudio and JDK 1.4
  • Index(es):
    • Date
    • Thread