<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>
<div>> Date: Mon, 12 Mar 2012 09:11:46 +1100<br>> From: lsd@wootangent.net<br>> To: linux-audio-user@lists.linuxaudio.org<br>> Subject: Re: [LAU] Popping sound at the start of every note on Bristol synths.<br>> <br>> On 12/03/12 9:03 AM, Rafael Vega wrote:<br>> > However, I've found that there is a popping sound at the start of every<br>> > note. This is more apparent in some models/presets than others. I'm<br>> > pretty sure my jack configuration is fine (has been working fine with<br>> > other synths, ardour, puredata, qtractor, etc.) and I've also tried ALSA<br>> > and two different sound cards (laptop internal and firewire). I also<br>> > tried outputting Bristol straight to system output, passing through<br>> <br>> It may just be that the attack on the amplitude envelope is too fast. <br>> I'm not sure if Bristol has this problem, but on many synths, with the <br>> attack time set to its minimum, the envelope opens instantaneously, and <br>> that can cause a clicking sound. Try increasing the attack time and see <br>> if that helps.<br>> <br>> Thanks<br><br></div><div>I had a listen through the sample you posted and agree that it is an issue with</div><div>the attack time, it was always very aggressive but there was also a recent change</div><div>from a default exponential to default linear attack which probably does not help</div><div>with what you are hearing. <span style="font-size: 10pt; ">You can change back to exponential from the config</span></div><div>stage however there is _another_ change that will go into the next release which</div><div><span style="font-size: 10pt; ">is probably the correct fix.</span></div><div><span style="font-size: 10pt; "><br></span></div><div><span style="font-size: 10pt; ">The change is to make the envelope 'time constant'. This is actually not the case</span></div><div><span style="font-size: 10pt; ">with the current code so if you increase the sampling rate you also increase the</span></div><div><span style="font-size: 10pt; ">fastest attack rate. The fix places the attack at 500us then gives you a rate which </span></div><div><span style="font-size: 10pt; ">is independent of the sampling rate. I can make this a config time option if people</span></div><div><span style="font-size: 10pt; ">are interested, it could be a runtime option which I think that is overkill but 500us </span></div><div><span style="font-size: 10pt; ">is </span><span style="font-size: 10pt; ">still pretty aggressive.</span></div><div><span style="font-size: 10pt; "><br></span></div><div><span style="font-size: 10pt; ">The maximum attack duration does not change, that is also </span><span style="font-size: 10pt; ">a config </span><span style="font-size: 10pt; ">option which </span></div><div><span style="font-size: 10pt; ">defaults to 10 seconds however having the parameters being a function of the </span></div><div><span style="font-size: 10pt; ">sampling rate was bad coding.</span></div><div><span style="font-size: 10pt; "><br></span></div><div>FYI some background on the changes: I have been doing work on 'low end'</div><div>systems where I default to half rate sample, 22KHz and 24KHz to reduce the CPU</div><div>footprint and hence extend battery life. At the same time I have been working on</div><div>high end systems where we have been reviewing the improved sound quality with</div><div>96KHz and 192KHz and these really exacerbated the problem. There are other </div><div>interesting results from the developments. The main filters are Huovilainen's which</div><div>are 2x resampling, this was required since the algorithm loses frequency accuracy</div><div>as it approaches Nyquist. At the higher rates I removed the resampling since the cutoff</div><div>frequency is now nowhere near Nyquist and the result is that, for the filters at least,</div><div>the change from 48 to 96KHz is almost free and you can still 'play' the filter at self</div><div>oscillation.</div><div><br></div><div>Let me review the code differences and perhaps post the new envelope.c on the</div><div>SourceForge forum. That might not be possible: the envelopes actually drive the</div><div>signalling to the engine regarding when to deactivate voices in polyphonic voice</div><div>assignments and I don't want any more sticky or lost notes where this signalling</div><div>might have changed.</div><div><br></div><div>Regards, nick.</div> </div></body>
</html>