# 96Khz seems to hangup the Server

**URL:** <https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438>\
**Category:** Getting Started and Wayfinding\
**Created:** [October 26, 2024, 4:49am UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438 "2024-10-26T04:49:08Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![areacode](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@areacode](https://discourse.flucoma.org/u/areacode)\
**Post date:** [October 26, 2024, 4:49am UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/1 "2024-10-26T04:49:08Z")

</div>

Hi all -  
I am running Plotter-4 from the Ted Moore YouTube link([https://www.youtube.com/watch?v=QvipZKrDwdU](https://www.youtube.com/watch?v=QvipZKrDwdU))…but I’d like to use 96khz samples.

I’m noticing that this crashes the SuperCollider server with this error:

```auto
Server 'localhost' exited with exit code 0.
server 'localhost' disconnected shared memory interface

```

Does FluComa work with 96kHz? Is there a different hopsize/fftSize that would impact this crash?

Thanks!

---

<div class="post-metadata">

**Author:** ![tedmoore](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tedmoore/32/439_2.png) [@tedmoore](https://discourse.flucoma.org/u/tedmoore)\
**Post date:** [October 26, 2024, 3:58pm UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/2 "2024-10-26T15:58:57Z")

</div>

Hi @areacode,

Can you provide us a bit more info? Does it crash when doing the analysis? Or just when trying to boot the server?

t

---

<div class="post-metadata">

**Author:** ![areacode](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@areacode](https://discourse.flucoma.org/u/areacode)\
**Post date:** [October 26, 2024, 4:20pm UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/3 "2024-10-26T16:20:47Z")

</div>

Yes - it starts to do the analysis - and gets partially through the slicing.

In my case, it seemed to get to 100 slices (out of 2400) before it crashed, so I removed this:  
`if((i%100) == 99){s.sync};`

This seemingly counted most of the slices…but then crashed at the next s.sync. So I removed the next s.sync and it still crashes.

---

<div class="post-metadata">

**Author:** ![tedmoore](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tedmoore/32/439_2.png) [@tedmoore](https://discourse.flucoma.org/u/tedmoore)\
**Post date:** [October 26, 2024, 4:37pm UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/4 "2024-10-26T16:37:14Z")

</div>

Because of the language-server relationship of SC sometimes the thing we see in the language isn’t accurately representing what’s happening on the server. For example, (I’d have to go revisit the code to remember exactly) even though it says it has processed the first 100 slices in the language, all that really means is that it has _sent the instructions_ for processing the first 100 slices to the server. So we can’t really be sure if it is even processing those 100 slices.

Removing the `sync`s is probably making it _more_ likely to crash.

Change `if((i%100) == 99){s.sync};` to just `s.sync;` so that it syncs on every slice (yes this will be slower) to see if it makes any progress then. If it gets through 2400 then maybe we can add `if((i%100) == 0){s.sync};` back in and slowly increase the `100` until it crashes and maybe that’s the amount of processing the server can handle without a sync to take a pause.

---

<div class="post-metadata">

**Author:** ![tedmoore](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tedmoore/32/439_2.png) [@tedmoore](https://discourse.flucoma.org/u/tedmoore)\
**Post date:** [October 26, 2024, 4:42pm UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/5 "2024-10-26T16:42:01Z")

</div>

It also would probably be useful to share the code so that we can eyeball it and make sure there aren’t other potential issues lurking in there that aren’t related to running at 96k.

---

<div class="post-metadata">

**Author:** ![areacode](https://discourse.flucoma.org/letter_avatar_proxy/v4/letter/a/848f3c/32.png) [@areacode](https://discourse.flucoma.org/u/areacode)\
**Post date:** [October 26, 2024, 4:55pm UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/6 "2024-10-26T16:55:23Z")

</div>

Just to clarify, the code is exactly that of plotter-4.scd from your video - I am just loading 96khz files instead of from FluidFilesPath. I’ll reproduce it below, for completeness.

s.sync on every slice seems to cause the server to idle in “yellow” permanently.

```auto
// define this big function, then way down below, execute it

s.options.sampleRate = 96000;
s.reboot;

(
~twoD_instrument = {
	arg folder, sliceThresh = 0.05;
	fork{
		var loader = FluidLoadFolder(folder).play(s,{"done".postln;});
		var src, play_slice, analyses, normed, tree;
		var indices = Buffer(s);

		s.sync;

		if(loader.buffer.numChannels > 1){
			src = Buffer(s);
			FluidBufCompose.processBlocking(s,loader.buffer,startChan:0,numChans:1,destination:src,destStartChan:0,gain:-6.dbamp);
			FluidBufCompose.processBlocking(s,loader.buffer,startChan:1,numChans:1,destination:src,destStartChan:0,gain:-6.dbamp,destGain:1);
		}{
			src = loader.buffer
		};

		FluidBufOnsetSlice.processBlocking(s,src,metric:9,threshold:sliceThresh,indices:indices,action:{
			"done".postln;
			"average seconds per slice: %".format(src.duration / indices.numFrames).postln;
		});

		play_slice = {
			arg index;
			{
				var startsamp = Index.kr(indices,index);
				var stopsamp = Index.kr(indices,index+1);
				var phs = Phasor.ar(0,BufRateScale.ir(src),startsamp,stopsamp);
				var sig = BufRd.ar(1,src,phs);
				var dursecs = (stopsamp - startsamp) / BufSampleRate.ir(src);
				var env;

				dursecs = min(dursecs,1);

				env = EnvGen.kr(Env([0,1,1,0],[0.03,dursecs-0.06,0.03]),doneAction:2);
				sig.dup * env;
			}.play;
		};

		// analysis
		analyses = FluidDataSet(s);
		indices.loadToFloatArray(action:{
			arg fa;
			fork{
				var spec = Buffer(s);
				var stats = Buffer(s);
				var stats2 = Buffer(s);
				var loudness = Buffer(s);
				var point = Buffer(s);

				fa.doAdjacentPairs{
					arg start, end, i;
					var num = end - start;

					FluidBufSpectralShape.processBlocking(s,src,start,num,features:spec,select:[\centroid]);
					FluidBufStats.processBlocking(s,spec,stats:stats,select:[\mean]);

					FluidBufLoudness.processBlocking(s,src,start,num,features:loudness,select:[\loudness]);
					FluidBufStats.processBlocking(s,loudness,stats:stats2,select:[\mean]);

					FluidBufCompose.processBlocking(s,stats,destination:point,destStartFrame:0);
					FluidBufCompose.processBlocking(s,stats2,destination:point,destStartFrame:1);

					analyses.addPoint(i,point);

					"slice % / %".format(i,fa.size).postln;

					s.sync;
				};

				s.sync;

				analyses.print;
				normed = FluidDataSet(s);
				FluidNormalize(s).fitTransform(analyses,normed);

				normed.print;

				tree = FluidKDTree(s);
				tree.fit(normed);

				// plot
				normed.dump({
					arg dict;
					var point = Buffer.alloc(s,2);
					var previous = nil;
					dict.postln;
					defer{
						FluidPlotter(dict:dict,mouseMoveAction:{
							arg view, x, y;
							[x,y].postln;
							point.setn(0,[x,y]);
							tree.kNearest(point,1,{
								arg nearest;
								if(nearest != previous){
									nearest.postln;
									view.highlight_(nearest);
									play_slice.(nearest.asInteger);
									previous = nearest;
								}
							});
						});
					}
				});

			}
		});
	}
};
)

~twoD_instrument.("/Users/w/Desktop/96kFiles/");

```

---

<div class="post-metadata">

**Author:** ![tedmoore](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/tedmoore/32/439_2.png) [@tedmoore](https://discourse.flucoma.org/u/tedmoore)\
**Post date:** [October 26, 2024, 5:09pm UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/7 "2024-10-26T17:09:54Z")

</div>

one thing to note is that you don’t actually need to run SC synth at 96k to do the analysis since `processBlocking` is a non-real-time process. so maybe try doing the analysis with scsynth at a lower sample rate.

also, can you print out the results of FluidBufOnsetSlice for us? (more than just the average number of slices: it would be good to know the length of all the slices!) It might be the case that there is a _very_ long slice that is clogging things up.

---

<div class="post-metadata">

**Author:** ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)\
**Post date:** [October 26, 2024, 10:39pm UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/8 "2024-10-26T22:39:12Z")

</div>

I can reproduce using your code (with both 96k files and 96k server, will figure out which of these matters later). The crash is in `FluidBufStats` – I’ll put an issue on github.

---

<div class="post-metadata">

**Author:** ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)\
**Post date:** [October 26, 2024, 10:44pm UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/9 "2024-10-26T22:44:44Z")

</div>

Issue here, should you wish to follow along

> <https://github.com/flucoma/flucoma-sc/issues/177>
>
> This may end up moving to core, and hopefully will get a better title. 
> 
> Crash… in SC server reported by user here: https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438
> 
> Can reproduce on my mac. Only have a release build stack trace so far, which isn't much use, but 
> \`\`\`
> 0 libsystem\_kernel.dylib 0x1826a0764 \_\_pthread\_kill + 8
> 1 libsystem\_pthread.dylib 0x1826d7c28 pthread\_kill + 288
> 2 libsystem\_c.dylib 0x1825e5ae8 abort + 180
> 3 libsystem\_malloc.dylib 0x182506e28 malloc\_vreport + 908
> 4 libsystem\_malloc.dylib 0x18251d5d4 malloc\_zone\_error + 104
> 5 libsystem\_malloc.dylib 0x182515148 nanov2\_guard\_corruption\_detected + 44
> 6 libsystem\_malloc.dylib 0x182514344 nanov2\_allocate\_outlined + 404
> 7 FluidBufStats.scx 0x105fac918 Eigen::PlainObjectBase\<Eigen::Array\<int, -1, 1, 0, -1, 1\>\>::resize(long, long) + 96
> 8 FluidBufStats.scx 0x105fa8e98 fluid::algorithm::MultiStats::process(fluid::FluidTensorView\<double, 2ul\>, fluid::FluidTensorView\<double, 2ul\>, double, fluid::FluidTensorView\<double, 1ul\>) + 172
> 9 FluidBufStats.scx 0x105fa8730 fluid::client::Result fluid::client::bufstats::BufferStatsClient::process\<float\>(fluid::client::FluidContext&) + 2436
> \`\`\`
> 
> So, an attempt to resize something in \`MultistatsProcess\` is making badness happen. I think I remember similar issues before where something reasonable-seeming with Eigen causes woe.

---

<div class="post-metadata">

**Author:** ![weefuzzy](https://discourse.flucoma.org/user_avatar/discourse.flucoma.org/weefuzzy/32/362_2.png) [@weefuzzy](https://discourse.flucoma.org/u/weefuzzy)\
**Post date:** [October 27, 2024, 12:02am UTC](https://discourse.flucoma.org/t/96khz-seems-to-hangup-the-server/2438/10 "2024-10-27T00:02:28Z")

</div>

Haha, my mistake. Not `FluidBufStats`, it’s `FluidBufLoudness`. I did something incredibly silly when we changed the code a couple of years back 🤦‍♂️

So, for now: `Fluid[Buf]Loudness` is broken at 96k and probably 88. I’ll push a fix soon, so the nightlies will work at least.