 Hallo, min name er Stian, og jeg er personen som revrott og porterede OpenCubiPlay over til Linux and BSD. Og så har mange som har en問, hvorfor? Og til å gjøre det, vil jeg støtte tilbake i tid litt til min kildere. Så den veldig første computeren min og min bror hadde var en alt Apple IIe. Og vi reviser det med et par gamle og et basiske tutorial. Så det har vært min curios til software-programmer litt. Og selvfølgelig har vi også en gammel gammel konsultat som vi kunne konekte til vår TV. Men som vi gav åldre, min gammel bror en computer. Og dette har en gammel spesifikasjon av en 33 MHz CPU som vi selvfølgelig har gammelt til 66 MHz. Det er en gammel 4 MB RAM, som vi selvfølgelig kunne gammel til 20 MHz, men ikke så mye. Og 200 MB storage. Og mest kan vi se at hvis du har en MP3-kollektion av musikk, så kan du ikke ha så mye musikk på denne computeren. Det betyr at i dag tilbake, vi hadde andre mennesker av musikk, som vi tilbake gammel modulfilen eller Amiga-modul. Men denne computeren hadde bare en PC-speaker, hva som er en beeper. Og jeg vil gjøre en liten kvitt demo om hvordan musikk skulle klare på en sånne machine. Så vi hadde en innrøsjere, som kunne faktisk oppgå audio til musikk. Og musikk-kollektion kom ut av speakeret, så det skulle være bedre enn dette. Men det var musikk. Så ja, vi skal få det ut av vegen. Jeg må få musikk ut. OK. Øst. Så, ja. Så, min bror, han decide at vi ville ha en bedre audio-kollektion. Så han bør en audiokard. Det var en klon av en samlasterkard. Og med det, vi kunne slett ha en bedre musikk, og vi kunne også ha musikk i våra gamene også. Og denne time, vi kan også ha access til en Qubit player, som jeg finner til å være en fantastisk software. Så vi får en dustbox opp og runner igjen. Tvere sekunder. Så du vil være presenteret med en filebrowser, simulat til dette. Og musikk vil være presenteret med en fin kolde. Og det var mye bedre også. Og for meg, min hele løpet av musikk var i software som dette. Så, ja. Jeg misser de dagene fra min løpet. Jeg har en nostalga for det. Så, for min computer, jeg begynte å lære programmet med Turbo Pascal. Og det var ikke så bra. Min løpet har en løpet av det. Alle bøkene ser ut til å løse på å gjøre, som en annen av musikkkollektjonen. Og det var en slags løpet. Du skulle lære om når de lødde de bøkene. Så, i høy skole, jeg lød en ny programmange, Delfi, som baser på Pascal, røpt inn på Windows, så jeg ikke gikk så mye mer ut av det. Men en kvart i klasse på meg, gikk meg til Linux. Og han gav meg en kopie av Linux distribusjoner på CD's. Og med dem var det også en slags løpet av alt. Og så kan du gå inn i det av hver del av musikk. Hvordan det gikk, kan du se en slags løpet, hvis du ønsker å gjøre sine ting. Du kan kopie pass fra andre ting. Så for meg, Open Source, var det en riktig åpner for å lære om hvordan programmet går. Men musikk i 2000, på Linux, var ikke så mye mer funnet. Vi hadde Mikmod til å spille modeller. Nå var det ikke noen kvart, men jeg gikk ikke å begynne å finne skjøntene på Google. Det var så gammelt. Og hvis du har en grafisk environment, du kan få XMS og simulater. Men det gikk ikke så mye mer, hvis du ønsker å spille old Amiga-filen. Det gikk ikke så mye om hvordan det faktisk gikk. Jeg miste det. Jeg hadde det old nostalgisk følelsen. Det kunne ikke så mye være skjønt. Så jeg kjente på QQubit-player, og en dag, de hadde renammet å åpne QQubit-player og å release Source. Yes! Og hvis nå er det open Source, det betyr at alle kan bruke den. Like, det er det som fungerer. Nei, det betyr bare at du kan kjente på DOS. Det har ikke vært så mye av Linux, så jeg følte at jeg var bortfattig. Men hei, hva kan du gjøre? Når du er gammel, du downloader den, og du tar en kvart inn. For meg, det jeg gjorde, var at jeg startet bare med en blank projekte, og jeg startet først til å kopi over denne funksjonen. Men vi skal først se litt om DOS. DOS er hva mange av deg har aldri used. Det er en disk-operating-system, og som benarbeid, det har en file-system API. Så, yes! Men, hvis du har grafikk, det betyr at din software skulle snakke direkt til grafikkartet. Så, det gjør ikke så mye til Linux. Memo-management. Hei, du har en megabyte memo, men programmet hadde access til CPU, og de kunne skjønne de memo-mapsen. Det er også en måte, programmet har vært only 16-bit, men programmet kan gjøre hva de vil. De kunne skjønne de CPU til 32-bit. DOS hadde ikke noe, og det var bare en singel process. Det var din software. Og senere, det er ingen sound API i DOS. Det betyr at alle software skjønne DOS direkt til grafikkartet. Hvis du hadde en multimedia software, DOS betyr at du hadde at du skulle implementere hårdighet for alle, og at din programmet eller grafikkartet skulle være en operatingssystem i seg selv, når du skjønner de moderne standardene. Så, ja. Jeg begynner å loke til min funksjon, Mainz, og skjønne det til en blank projekte, og se om du kan skjønne. Og først, å begynne å vise at mange ting kan være skjønne. Hvis du skjønner om du hadde en virus-infekt i DOS, det skjønner ikke noe. Så det kunne vi bare skjønne. Så, næste betydelse det gikk, var til en liste av initialiser. Det første i denne initialiser var til å konfigure alle intervjuer. I Linux, så kan vi bare skjønne. Næste betydelse var faktisk support for DLL-filen i DOS. Det er så spørselig, da mange mennesker ikke DOS har DLL, men de ikke har DOS, men siden Sikomparlis hadde sitt support for DOS. Men hei, i Linux, vi har noe simpelt. I LibC kan vi åpne SO-filen med nogle byggende funksjoner i LibC. Så mange av disse funksjoner kan vi bare skjønne og sikkert tilbake. Så API-konversjoner hadde det vært gjort. Så DLL, som vi har sagt, de kan vi re-map til LibC sin egen implementasjon. Næste betydelse er det utdående avlevet. I Linux er det mer oplevelse om man har en app used end-curses. Or g vaccinated in a console you can actually get direct access to the buffers using special devices. Keyboard input is also quite simple actually in linux, we either use end-curses or read standard input. And you can map-up all of the special keys og opp og ned. Næste ting på listet var audio-mixer-routinen. De var skrevet i Assembler. Så de som vi ser næste slik, jeg hadde til å reivere dem så de kunne kompile med GCC. Audio- og hårdere driver. I Linux har vi den vantige at Linux kan handle audio for oss. Og dette gjør vi enten med å bruke opp sommer eller ALSA. Nå har jeg også skrevet support for X11 og SDL. Så vi har en stor matrix av olika input- og output-systemer. Det gjør det også mulig å runne på en ganske stor kollektjon av olika Unik Space OS. Men selvfølgelig, det går ikke alltid. Den første problemet er når en person runner dette på en ganske old Mac. En riktig ganske old one. Den har en N68K CPU. Og det har en annen andien. Og noen av de som aldri har hørt om en andien før. Så du har en kvitt introduksjon til det. Så først, hvis vi har en mærke som en lang list av adresser. Hver adress kan stå en byte. Så hva du gjør når du vil stå to byte til dette systemet. Nå kan du choose to have one byte before the other and both are correct. This is called little and then and big and then. Different CPU architectures and file formats choose to implement different ones. And why to choose? I don't know. It means that whenever you load a file, we need to be aware of which and then it is stored in and converted to whatever your local CPU actually expects. So with that out of the way. I mentioned that original mixers were written in assembler. And this was probably chosen because C compilers and C++ compilers back in the days were not very efficient with the code they produced. The machines were not super fast. So with code that really very important would be handwritten in assembler. And you would call up these functions from your program. I initially chose to keep assembler mostly as is. Hard to see on the slide, but I was put this inside a little wrapper and you can glue it into C as is. But you need to inform GCC which registers are used as inputs and outputs. And suddenly GCC can use the assembler block as is. But this is not very compatible when you want to have different CPUs and also when you want to have 64-bit support. So all of the assembler functions need to have alternative versions in C. And even have one contributor writing the one assembler functions to C for the floating point unit. So I didn't have to do everything myself. So let's jump. Backround idler. Back in year 2000s machines were still a bit slow. And if you open the file browser inside QB Player, the music would every now and then skip a bit. So I choose to look at how this was sold in DOS. They would use a timer interrupt. And in Linux, you don't have interrupts in a program. But for timer, we have something similar. We have something called SIG Timer. And you can instruct the kernel to give you a signal on that signal handler at a given interval. So I chose to copy-paste the original code from QB Player for this. But it kept on locking up my console. And early early in the night I initially did not know why this happened. So I was able to get out a little piece of code and initially thought it would be a bug in my code or GCC and that my code just simply locked up my terminal but machine was still okay. It turned out to not be that. It turned out that I had hit a zero-day exploit by pure accident. So it turns out that the FPU is actually async with the rest of the CSCPU core. So when you do a store and restore of all the registers in the FPU, it doesn't happen immediately. It takes a little time before it actually happens. And what I did in the original code that I kept from DOS is I wanted to preserve the state of the FPU. Because I didn't know if this was necessary to do or not in a SIG timer. And I had by mistake left out a little star. And so the pointer was not D reference enough amount of time. So this code actually crashed but the crash didn't happen immediately. It happened after the code returned back into the kernel space. And the kernel space exception handler for the routine didn't expect this kind of things to happen. So it kept on trying to restore the FPU over and over and over again. So you basically had a DDoS attack as long as you had a login access. So let's jump back in time to see how music used to be done before. And this chip looks like a weird name. It had many different names. It was sold under many different brands. And if we look deep inside it we can see that it has a little pattern. We have three different pulse generators, they named it. Today we'll probably just call it square wave generators and a simple noise generator. For each channel you could choose to use the pulse generator or the noise or both. They added what they named a global envelope generator. Very advanced name. Basically it's a shape you can choose and you can choose how fast this shape goes and this can be used as your source for the volume adjustment. And each of the three channels could then choose one of these to either choose the global envelope generator or a statically set volume. So how does this actually sound? Let's start a little demo program. So this is what, a little louder. So we don't have so many knobs we can twist and turn. But hey we can make sound. Let's get that closed away before we kill any more ears here. So next slide. So this chip had then three square wave audio outputs and was used in a big selection of products. Including the ZX Spectrum 128 CPC, Atari ST and common for all of these machines are that they have very small amount of memory and there were no standardized way for how the music should be stored and play back and also a very limited amount of processing power per frame which is why many games also only had music at the intro and not during the game as well. And at two different occasion I got asked if I could implement support for different kind of music from games. The first one was to use Islet which is a library that emulates the CPU and the sound chip from the ZX Spectrums and some similar machines and the other request was Eon files which is using SD sound library this one instead of emulating the CPU it just has stored one long dump of what the registers were. So how did this music sound? So we can have music. Yes Music is nice but how did they actually make this music? If we look into a dump of the music from one of those games it's actually machine code it was handwritten and either the music composer needed to learn how to make machine codes or the music author needed to cooperate with a programmer and they need to cooperate for how to store the music and how it should be played back. Next up, next iteration of soundchips happened with the Commodore 64. Here they choose to have instead of only square waves they added support for sawtooth and triangles as well. And instead of having one global volume generator each channel has its own has its own they call it ADSR which is attack, decay, sustain and release. Which basically means that you can choose how one specific voice will how fast it will turn on and how fast it will turn off again when you play a note. And many people also say that one big change for this was that they added filters that you could actually low pass and high pass the audio. So let's do a quick demo for this chip as well. So suddenly we have way more knobs we can turn there. So how did music sound and then win this with the chip. And I was lucky that the music played just recently was available on the Commodore 64 as well. So this is why Commodore 64 is said to be a very important change for how music sounds. Because it's still only three voices but since you have much more control of what those three voices do the music sounds better. So Commodore 64 also had more memory personal standard which means that the audio routines for rendering the music could also be bigger. Which means that more games would actually feature music as the game was playing and not just during before the game in the introduction. Yeah Yes So Next thing up Yes also the implementation of playing back this music is using lib sidd play which is another open source project. And as well sidd files music is still done using machine code. So not much has changed there though. So what's changed then in the PCs we were starting to see something named OPL chips. And these chips would feature up to nine channels each channels would have two operators that were working in the same frequency but they could be offset to have different harmonics. These could either play audio at the same time or they could be looped back together. So that one output of the first operator would be added to the frequency into the second operator. And they had a total of nine channels. Three of these channels could be replaced with drums. So how does this chip then sound like? Suddenly we got even more knobs we can twist and turn. Let's do different harmonics for the operators. But one thing that changed a lot since Commodore 64 is that all of the sounds are based on sine waves. So let's do a super quick demo of what music sounds like with this chip. So this will be the typical music of the start of the DOS era. So what other chips did we have around in the world? So Commodore didn't give up even though the PCs were coming to the market they come up with Amiga. And on Amiga we had a sound chip and they removed the idea of having these synth generators. Instead you would play back audio samples. And you could choose how fast these audio samples are played back which gives you different notes and you can adjust the volume. The Amiga features two channels for the left speakers and two for the right. So a typical music editor on Amiga would look like this. We have four major columns controlling each of the four channels on the sound chip. Each of these columns you can subdivide into a note which gives you the initial pitch of a note. We give it an instrument so typical Amiga modules initially only had typical support for each instrument, hence only one digit. You could have a volume effect and parameters to that effect. So what kind of effects could we expect to do with this sound chip? It's so basic in design, right? You can actually do quite a lot by adjusting the pitch alone. Adjusting the pitch alone you can probably do most of the things you can do on an electric guitar. Dragging your hand up and down or vibrating all kinds of effects. Same also with the volume where the volume you can slide up and down or you can do tremolo by vibrating it quickly on and off. Next generation of audio in games. First come the question what was music? Well, you could divide music into instruments and note sheets. And here a new standard come up with keyboards. General MIDI. They went through all of the instruments and made it into a long database. With major groups like pianos, drums, organs and music sheets. A MIDI file has 16 channels. Each channels you can look up as an actor. Which means that you can only pay one kind of instrument at any given time to change what kind of instrument it has. So MIDI is basically a 16 person band. And the note sheet you can convert into a list of events when to turn on and off different notes and what instruments to play. In order to support MIDI files we use Timothy. It's a very old project that loads sound fonts and renders the events given in the MIDI file to an audio stream. So, others file formats. MP3 files were used to doing by using amp. Which is an old, old engine to decode MP3 files. It is buggy and instead of bug fixing it it was easy to just use libmod which basically all this distros has installed anyhow. Same with org files, flag files. All of those are standard available in a distros. So just use the library. And the files was already built in. It's very basic, easy to parse them. So, do I get requests for new formats? Yes. But luckily many of them are already open source and you can copy paste in and out from them. So, last slide. Thank you all. And making a project open source is not a negative thing. It makes it possible for you to get feedback, bug fixes, and if you abandon projects, others can pick it up and convert it. So, thanks to the original authors of cubic players, contributors, and all different libraries that are open source that you can use as is or copy paste out of. And some example sources of music. Thank you. I don't think we have much time for questions. Yeah. So, if you have any questions you can either send them to foster or you can grab me out in the hall.