<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<meta content="text/html; charset=UTF-8">
<style type="text/css" style="">
<!--
p
{margin-top:0;
margin-bottom:0}
-->
</style>
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif">
<p>Hi Tim, thanks for the background! So most likely, I will implement some kind of infinite NullSound to work around the issue.</p>
<p><br>
</p>
<p>But then my profiler stack must be wrong? Is this an issue with MessageTally?</p>
<p><br>
</p>
<p>Best,</p>
<p>Christoph</p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:rgb(0,0,0); font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family:Calibri,Arial,Helvetica,sans-serif; font-size:; margin:0">
<div>
<div class="x__rp_T4" id="x_Item.MessagePartBody">
<div class="x__rp_U4 x_ms-font-weight-regular x_ms-font-color-neutralDark x_rpHighlightAllClass x_rpHighlightBodyClass" id="x_Item.MessageUniqueBody" style="font-family:wf_segoe-ui_normal,"Segoe UI","Segoe WP",Tahoma,Arial,sans-serif,serif,EmojiFont">
<div dir="ltr">
<div id="x_divtagdefaultwrapper"><font face="Calibri,Helvetica,sans-serif,EmojiFont,Apple Color Emoji,Segoe UI Emoji,NotoColorEmoji,Segoe UI Symbol,Android Emoji,EmojiSymbols">
<div id="x_Signature">
<div style="margin:0px"><font style="font-family:Calibri,Arial,Helvetica,sans-serif,serif,EmojiFont">
<div><font size="3" color="black"><span style="font-size:12pt"><a href="http://www.hpi.de/" target="_blank" rel="noopener noreferrer" id="LPNoLP"><font size="2"><span id="LPlnk909538"><font color="#757B80"></font></span></font></a></span></font></div>
</font></div>
</div>
</font></div>
</div>
</div>
</div>
</div>
<div><font size="2" color="#808080"></font></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von tim Rowledge <tim@rowledge.org><br>
<b>Gesendet:</b> Montag, 28. Juni 2021 20:26:56<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] Many questions about sounds :-)</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText"><br>
<br>
> On 2021-06-28, at 4:12 AM, Thiede, Christoph <Christoph.Thiede@student.hpi.uni-potsdam.de> wrote:<br>
> <br>
> Ah, that's interesting. :-) But why is "[] newProcess" blazing fast whereas the invocation in the SoundPlayer is so expensive? Is this somehow related to the resources (closure vector) that need to be shared in this case?<br>
<br>
This almost nothing at all to do with the costs of starting a Squeak Process - which are quite close to 0 - and almost entirely the costs of starting the platform sound system, getting the samples into the platform sound system buffers, and said sound system
actually getting around to making speakers wobble back and forth. Another layer of possible time-spending is the fairly complex code in SoundPlayer class>>#playLoop and its friends.<br>
<br>
I'm not certain, but I also suspect that only Mac has actually functional quick-start code in the sound plugin.<br>
<br>
It might be instructive to insert some time tagging to measure how long it takes from sending the sound buffer to the OS until the actual sound comes out. And indeed how long from asking Squeak to start playing until it gets to the OS buffer.<br>
<br>
tim<br>
--<br>
tim Rowledge; tim@rowledge.org; <a href="http://www.rowledge.org/tim">http://www.rowledge.org/tim</a><br>
Old programmers never die; they just branch to a new address.<br>
<br>
<br>
<br>
</div>
</span></font>
</body>
</html>