[squeakland] Question about Audio Buffer/Timing

Jeremy Landry hakyoku at gmail.com
Thu Feb 22 19:32:22 UTC 2018


This is a demo of the problem for ETOYS 5 (along with some other stuff
there that shows what I've looked into, to some degree).  Hitting play on
the scriptor, you will hear a sequence that has awful timing.  I don't
expect 'sample perfect', zero latency or anything spectacular, but it would
seem that if there's timers in the system, everything should adhere to it,
or else not be called timers and something like,
'when-we-get-around-to-its'.  This video here demonstrates that Squeak, at
least, can do timing just fine and older versions have midi demos, but
again, I'm using Etoys for a specific reason, so it's confusing me as to
why the delays happen...

Both sequencers are mouse interactive and playing with the script timer and
setting blocks on/off can reveal this hidden metronome...maybe that IS the
buffer?  I'm not sure...what's most puzzling is that sometimes it will
sound right, and sometimes it won't...even if it wasn't correct, I'd
probably be okay if it was consistently incorrect because I can actually
work with consistency, so I guess if nothing else, that's what I'm trying
to figure out how to get without making tile usage unavailable for a
sequencer built on etoys tiles...

Thanks for all the efforts so far...I did notice some changing in the
timing when I checked the preference there but also unchecked the
preference of stopSoundsWhenDone, just in case it was hiccuping by shutting
down the sound stream then making a new one.  It didn't help, but I had
forgotten about these preferences.

On Thu, Feb 22, 2018 at 10:57 AM, Bob Arning <arning315 at comcast.net> wrote:

> There do seem to be some platform issues as to whether this will really
> work. Some things you could do:
> - check the value of the Preference for #soundQuickStart -- make it true
> if not already
> - put some code into the SoundPlayer method to tell you if quickStart is
> being requested and if not honored, why
> On 2/22/18 1:22 PM, Jeremy Landry wrote:
> Thanks for the crossover.  I am subscribed, but generally shy away from
> posting there as it seems out of my league and my main interest is in Etoys
> since, well, again, leagues and all that.  I know just enough ST to break
> things, not build them!  :)
> So using the code from this message from Bob Arning:
> *Bob Arning* arning315 at comcast.net
> <squeak-dev%40lists.squeakfoundation.org?Subject=Re%3A%20%5Bsqueak-dev%5D%20%5Bsqueakland%5D%20Question%20about%20Audio%20Buffer/Timing&In-Reply-To=%3C269cdd30-7c77-6cab-22aa-591eee543b21%40comcast.net%3E>
> *Thu Feb 22 15:49:07 UTC 2018*
>    - Previous message: [squeak-dev] [squeakland] Question about Audio
>    Buffer/Timing
>    <http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-February/197505.html>
>    - Next message: [squeak-dev] [squeakland] Question about Audio
>    Buffer/Timing
>    <http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-February/197509.html>
>    - *Messages sorted by:* [ date ]
>    <http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-February/date.html#197508>
>     [ thread ]
>    <http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-February/thread.html#197508>
>     [ subject ]
>    <http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-February/subject.html#197508>
>     [ author ]
>    <http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-February/author.html#197508>
> ------------------------------
> SoundPlayer class gives a clue:
> resumePlaying: aSound quickStart: quickStart
>      "Start playing the given sound without resetting it; it will resume
> playing from where it last stopped. If quickStart is true, then try to
> start playing the given sound immediately."
> Just looking at it and taking a guess, it doesn't seem to be *quite* the
> thing I was looking for.  I was thinking there's a method/class variable
> with a value that could be changed to affect the system, rather than
> 'poking in' every thing I want to play when I want to play it individually
> because the ultimate effect is that Etoys PLAYSOUND:SOUND tile will work as
> normal and this seems that it would have to be used instead of the
> tiles...I have no idea if this is possible, but I'll also dig around the
> class browser in Etoys, maybe I'll stumble into something, but so far, as I
> noted, I only found the sound-buffer and sample rates, not the imposed
> delay method that I remember reading about.  I remember the reasoning it
> was put in was to prevent accidental playing of sounds inside of a
> single-frame repeat-tile...i.e. a repeat tile with any value other than 1
> and inside of it having a playsound:sound tile would overload the speakers
> and make nasty noises because so many things are playing on top of each
> other. I actually WANT this.  Based on how sound plays now, you can hear an
> 'invisible' metronome that makes sure all sounds are separated and equally
> spaced apart and in the case of repeat tiles, only seems to accept the last
> sound as valid/playable.
> Thanks for the help so far!  I'm not expecting a solution because I don't
> know if one exists, but my thought is 'if it was done, it can be
> undone'...and just looking at how to undo it!  :p
> On Thu, Feb 22, 2018 at 9:59 AM, David T. Lewis <lewis at mail.msen.com>
> wrote:
>> There is some follow up discussion happening on the squeak-dev list. I
>> don't
>> know if it helps, but you can read the posts here if you are not
>> subscribed to
>> that list:
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-
>> February/197508.html
>> HTH,
>> Dave
>> On Thu, Feb 22, 2018 at 10:27:18AM -0500, David T. Lewis wrote:
>> > Hi Jeremy,
>> >
>> > I am copying this to the squeak-dev list in case someone there can offer
>> > some guidance.
>> >
>> > Dave
>> >
>> >
>> > On Wed, Feb 21, 2018 at 02:44:21PM -0800, Jeremy Landry wrote:
>> > > Hi, I made a quick audio sequencer test in Etoys and found that
>> there's a
>> > > hidden 'timer' that limits the responsiveness of new sounds that go
>> into
>> > > the playback buffer (terminology isn't accurate, but hopefully it
>> makes
>> > > sense to people).
>> > >
>> > > I found the sound buffer setting, but was wondering if there's
>> something
>> > > else that limits how fast new sounds get added to the playback
>> stream? I
>> > > read somewhere (old-man-aphasia here) that some code was added to
>> prevent
>> > > overloading the buffer so surely there's a snippet of code I could
>> add to a
>> > > project to reverse this, if it's what is causing the delay?
>> > >
>> > > Thanks for any help finding the solution.
>> >
>> > > _______________________________________________
>> > > squeakland mailing list
>> > > squeakland at lists.squeakland.org
>> > > http://lists.squeakland.org/mailman/listinfo/squeakland
>> >
>> > _______________________________________________
>> > squeakland mailing list
>> > squeakland at lists.squeakland.org
>> > http://lists.squeakland.org/mailman/listinfo/squeakland
> _______________________________________________
> squeakland mailing listsqueakland at lists.squeakland.orghttp://lists.squeakland.org/mailman/listinfo/squeakland
> _______________________________________________
> squeakland mailing list
> squeakland at lists.squeakland.org
> http://lists.squeakland.org/mailman/listinfo/squeakland
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakland.org/pipermail/squeakland/attachments/20180222/c90eb27d/attachment-0001.html>

More information about the squeakland mailing list