[00:01] got a working compile: http://erebor.db48x.net:8000/example_macplus.html [00:01] sound sounds pretty good [00:01] occasional buffer underrun messages, some popping [00:16] Wow, that IS nice [00:16] throw that sucker in [00:46] SketchCow: thrown [00:53] unsure if we can improve this buffer underrun trouble, on my PC I get a lot of them with this example [00:54] agreed [00:54] but I think we can fix the really bad pops at the beginning of sounds [00:54] I use headphones, and they are super bad [00:54] but overall it's an improvement [00:55] macplus use two 370 sample buffer, either the SDL port or the browser want only power of two buffer size, that prolly increase the number of underrun [00:55] Do you think it's good for 1.0 or do you want to do more tuning? [00:56] dunno what can I do now, as I work on Hampa code and it's very good on it [00:56] phe: I'm not sure the buffer size is so important [00:57] if I understand it correctly, SDL is calling our callback whenever it gets near to running out of data to play [01:00] in fact, a quick experiment with a smaller buffer size seems to have helped [01:00] I don't know how the emulator fill the buffer, we can run in sdl ask 512 sample, a buffer contain 370 samples but does the emulator flush the buffer sample by sample [01:00] we're less likely to be asked for 1024 samples when we only have 370*1.437 available [01:00] yeaj, I tried, and reversely increasing the buffer size add a lot of overrun [01:02] on the other side, decreasing the buff size increase the number of scratch at buffer boundary [01:02] I think the scratches are purely underruns [01:02] try erebor again; it's great [01:02] compare that with https://archive.org/details/mac_DarkCastle_1_2 [01:03] erebor has the sdl buffer set to 256 samples [01:08] hmm, with chrome erebor give me around 50 buffer underruns per second [01:11] ff nightly look like flawless, I get an underrun at the end of each music cycle, I think it's sort of normal [01:15] disappointed by chrome webaudio support [01:16] hmm, I get more problems in chrome as well [01:16] well, we can always tell people not to use chrome [01:17] yeah, when I forced emscripten sdl port to accept 22255 as input freq, ff and chrome accepted it, but only ff resampled it [01:17] nice [01:18] phe: I was also looking at using SDL2, which has SDL_AudioCVT [01:18] I remember, why it didn't work? [01:19] looking at SDL2 the code, if you pass NULL as second parameter to openAudio, it should try to build a resampler filter [01:19] build trouble, errors at run time [01:20] heh [01:20] with SDL2 there is no need to build a filter, same for sdl1 [01:20] that's exactly what the code used to do [01:22] but I'm unsure if sdl will be able to build a filter for 22255 [01:22] I traced sdl1 code with Hampa code, it's not sdl1 which accepted that freq, but the underlined audio driver [01:23] phe: what do you meant? [01:23] the 22255 sample rate is from the original mac hardware [01:23] so it's naturally that it's exactly what PCE produces [01:25] yes, it's what Hampa emulator request to sdl, SDL first try if the box audio device driver accept that directly before doing trying a resampling [01:25] I see [01:26] yes, and so you think that the reason the sound wasn't right all along is that the SDL port fails to build a filter that can resample from 22255 to whatever the browser wants? [01:27] I'm saying that because I'm unsure if sdl1/2 if the device driver can't acecpt that freq will be able to do the conversion [01:27] yeah [01:27] well, that would explain why it wasn't just working [01:27] we should file a bug on SDL (or I guess the port) and see if we can get it fixed [01:29] I doubt it's fixable, if they do resampling by integer step [01:30] 22255 = 4451*25, 4451 is prime, they'll need a temp buffer 4451 bigger than the initial buffer [01:37] https://github.com/emscripten-ports/SDL2/blob/778fe55bd884cf301a8bda51445f72b24816b648/src/audio/sdlgenaudiocvt.pl#L368 [01:39] I was looking at https://github.com/emscripten-ports/SDL2/blob/master/src/audio/SDL_audiocvt.c#L937 [01:40] and https://en.wikipedia.org/wiki/Upsampling#Upsampling_by_a_rational_fraction where L and M can only be integer [01:41] hmm, so emscripten look like to be able to do that [01:43] ah, but look at line 934 [01:46] it does indeed bail on this conversion [01:46] but https://github.com/emscripten-ports/SDL2/blob/master/src/audio/SDL_audiocvt.c#L1048 [01:47] all of this code look like voodoo [01:47] I'll be conceived it works when I'll see it working :) [01:48] convinced* [01:48] :) [01:48] I guess there must be a generated filter where multiple == 0 [01:48] it would just copy directly, rather than doing any actual resampling [01:49] so what you tried is to use the pl script to build a filter, or emscripten automate that? [01:50] unsure to understand how that work [01:50] I'm assuming that the perl script is run when you build the port [01:53] ah, no. I am wrong [01:53] look at SDL_audiotypecvt.c [01:58] https://github.com/emscripten-ports/SDL2/blob/778fe55bd884cf301a8bda51445f72b24816b648/src/audio/SDL_audiotypecvt.c#L15702 [01:58] specifically, it'll find this one: https://github.com/emscripten-ports/SDL2/blob/778fe55bd884cf301a8bda51445f72b24816b648/src/audio/SDL_audiotypecvt.c#L15726 [02:07] so the upshot is that the SDL port doesn't have a resampler that can actually resample by an arbitrary amount, so we either have to fix the port or just do it ourselves [02:07] we've done the latter, aside from possibly a bug, so I guess we're good [02:08] nice: https://github.com/emscripten-ports/SDL2/issues/38 [02:22] SketchCow: oh, I need to upload new config files for pce as well [02:23] I put them in the loaderlab [02:27] OK, I don't think it can happen until Monday [02:27] I can try [02:27] Depends on dev mood [02:28] heh [02:28] fair enough [02:28] bbiab [02:36] What are the differences in the newloader? [02:36] And is it just loader.js? [02:36] Or which files? [02:44] even if we rebuild audiocvt.c, the generated resampler doesn't look like good: https://github.com/emscripten-ports/SDL2/blob/778fe55bd884cf301a8bda51445f72b24816b648/src/audio/SDL_audiotypecvt.c#L3736 [02:46] they replicate the same sample up to the fractional part then inject the new with half of the last [02:56] *** phe has quit IRC (Quit: Leaving) [02:58] Some questions [02:58] - What is the difference in the new loader [02:58] - The sound sounds good except for that initial "crunch" as it engages - is there a way to mute that opening frame? [03:13] Many people worked very hard to bring this emulation system to bear: Hampa Hug created PCE (the original Macintosh emulator program). Experiments and work by James Friend (PCE.js) and Marcio T. (Retroweb) ported PCE to javascript via Emscripten. They all provided continued assistance as the Emularity team approached refining the emulator to work within the Archive's framework. Much work was done by [03:13] Daniel Brooks, Phil-el, James Baicoianu, and Vitorio Miliano, with Daniel Brooks putting in multiple weeks of refinement. [03:14] Let me know where I'm off [03:39] SketchCow: I haven't changed loader.js at all [03:39] SketchCow: just pce*.cfg [03:39] I can't uploade to emularity_config_v1, so I just stuck them in loaderlab for you to deal with [03:39] Ah hah [03:39] ah HAH [03:39] Well then [03:39] AH HAH [03:39] hhahhhhh [03:40] :) [03:43] I shoved them in [03:43] What did it do [04:02] set speed=1 [04:03] which makes the emulator run at a constant rate, rather than trying to scale up and down [04:03] I had also forgotten to add foo.qed as possible disk images to look for [04:03] so it corrected that [04:05] Great [04:05] So, I do wonder about that slight grinding noise at the beginning of the sounds [04:05] I notice it's almost as part of the noise, like it's gearing up [04:06] Once it's "going", it's fine [04:10] with headphones I think it's more obvious [04:11] it's the kind of pop you get when the speaker is driven to maximum and held there [04:12] DC offset [04:15] yes, and my first thought was that we were doing the wrong signed/unsigned stuff [04:15] like treating 0 as silence in an unsigned buffer, instead of 0x8000 [04:16] but we are resampling into a signed buffer, so that part seems right [04:18] https://www.youtube.com/watch?v=UndXYYosDk4 [04:41] Maybe we announce this Monday if we find things humming right [06:51] *** db48x has quit IRC (Read error: Operation timed out) [06:53] *** db48x has joined #jsmess [10:17] *** phe has joined #jsmess [13:43] I got Stephen Cole to begn uploads of new Mac things, which is great. [15:03] https://archive.org/details/MacintoshSharewareGames [16:53] Still working on blog entry [16:58] db48x: Question [17:14] Actually, phe too [17:15] Here's the questions: [17:15] - Do we think that buzz/offset at the beginning of each sound set can be eliminated? Should we wait for it? [17:15] - Do you think I can announce this today or this weekend or whatever without embarassment? [18:43] https://github.com/copy/v86 looks interesting [18:43] win98 runs smooth af [19:14] so i found out about this site: https://winworldpc.com/ [19:15] nice [19:15] just archives or do they have some embedded emulator stuff going somewhere too? [19:16] just archives [19:16] its where that guy got the windows 98 from [19:16] ah cool [19:18] i still think we need to find unopen computers to grab a hard drive image of them [19:19] yeah I have a box of old hard drives going back to the 90s [19:19] I took backups of all the ones I could still interface with but there's some scsi and pata stuff which I'd have to dig into boxes to find controllers for [19:19] anways CAT [19:20] I love the idea that I could just image my old system and boot it right up [19:20] same here [19:32] we should throw it in [21:43] I imaged an OS9 system and brought it right up in QEMU a few weeks back [21:44] v86 is one of the things I need to make time to bring up a full Win95 instance with to test Unrealty with [21:54] sample0: 0, sample1: -32768, frac: 0.000000, sample: 0 pce-macplus.js:1:366844 [21:54] sample0: 0, sample1: -32768, frac: 0.695469, sample: -22789 pce-macplus.js:1:366844 [21:54] sample0: -32768, sample1: -32768, frac: 0.390937, sample: -32768 pce-macplus.js:1:366844 [21:54] sample0: -32768, sample1: -32768, frac: 0.086406, sample: -32768 pce-macplus.js:1:366844 [21:54] sample0: -32768, sample1: -32768, frac: 0.781875, sample: -32768 pce-macplus.js:1:366844 [22:04] why the input contain only -32768? [22:06] btw db48x in the buffer underrun if (), there is a return at end, it must be a break so the part of the output buffer we get pass through the lowpass filter [22:10] phe: that's true [22:16] I'm running again in trouble with chrome, -O0 build work a lot of better than any -Ox, 3-4 buffer underrun vs 100-200 with -O2/-O3 [22:20] that's promising [22:20] how does -O0 run in Firefox? [22:20] you might also try -Os [22:21] it works well in FF whatsoever the opt level [22:22] but we can't do non optimized build because he js is 1.3 MB vs. 4 MB [22:26] Initializing SDL audio threw an exception: "Invalid SDL audio format 16!"! Continuing without audio. [22:27] -Os doesn't help chrome [23:24] phe: the input must actually be unsigned [23:28] hmm, req.format = AUDIO_S16LSB; [23:29] I thought it's signed but most manipulation on it is done as unsigned, as it doesn't matter when you only copy [23:33] snd_iir2_filter use uint16_t * input but in the same time it get drv->sign which is 1 so it can handle data correctly [23:38] but you're right, I should handle that like the remaining of the code, as uint16_t, it'll change nothin to the result