PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: Bonknuts on October 31, 2015, 07:39:46 AM
Title: Some audio stuffs
Post by: Bonknuts on October 31, 2015, 07:39:46 AM
I posted here: https://pcedev.wordpress.com/2015/10/31/pcm-player/
tl;dr
Quote
On the topic of audio, have you guys ever heard the PCE stream 55khz 5bit PCM using the channel’s waveform memory as a buffer? Check it out: http://pcedev.net/6280a/sgx_dump.wav That was recorded from my SuperGrafx.
So, basically I know what I can do on the SGX or more specifically the 6280a, but I wanted to get some recordings from PCE owners (6280), if possible. I'll post a few demos. I'm looking for recordings like the one above and what console it was recorded from.
Title: Re: Some audio stuffs
Post by: touko on October 31, 2015, 10:47:08 AM
Great, i always wanted to know what's the max PCE's frequency for PCM .. 55khz is awesome, but i think (even if it's useless) it could be higher ??
Title: Re: Some audio stuffs
Post by: Bonknuts on October 31, 2015, 11:28:05 AM
Supposedly, up to 3.5mhz if you can write to it that fast - lol. With a 7khz interrupt, you can output 224khz if you use all 32 bytes in the waveform buffer.
Title: Re: Some audio stuffs
Post by: elmer on October 31, 2015, 12:18:56 PM
I'm still clueless as to why they put the 6280a in the Core, but not in any of the other PCE systems. Any thoughts?
Same reason the SuperGrafx (which also has it) wasn't supported. The PCE as it was, was already good enough and proved it by going the distance.
Except that the improvements in the 6280a are minor enough that I doubt they increased production cost, and they clearly already had the ability to manufacture the chips. That's why I'm confused. It seems like it should have been one of those seamless upgrades nobody would have noticed.
Title: Re: Some audio stuffs
Post by: Black Tiger on November 05, 2015, 12:59:41 PM
Just read the blog post. 29% cpu resource for 4 XM channels is pretty amazing since Air Zonk does everything it does with 21% wasted on audio. I'm guessing that 6 channels would be fine running with most sections of an RPG.
Title: Re: Some audio stuffs
Post by: touko on November 05, 2015, 07:29:06 PM
Quote
since Air Zonk does everything it does with 21% wasted on audio.
Yes airzonk's driver sucks . I have a driver with compression/buffering and banking it uses 3/4% per channel .
Title: Re: Some audio stuffs
Post by: ccovell on November 05, 2015, 08:54:07 PM
Just read the blog post. 29% cpu resource for 4 XM channels is pretty amazing since Air Zonk does everything it does with 21% wasted on audio. I'm guessing that 6 channels would be fine running with most sections of an RPG.
Airzonk is a lot higher than 21% cpu resource. Just to be sure, before posting this reply, I took 10 readings from the game's TIMER interrupt. The actual cpu resource floats between 29% and 33%.
It was at 33% when it had to reload the bit shifter (decompress the samples), which if I recall is every three samples or so. It was about 30% for just playing the sample. That doesn't include any music engine stuff (reading the byte code music for the normal channels). I made sure the samples (sampling of the code) I read didn't touch that part (that would give a false reading). So 30% just for playing the samples, and whatever cpu resource for regular channels.
For an RPG, I think you could get away with almost 70% cpu resource dedicated for audio (if the game is coded in assembly). That would allow much higher rate sampled channels.
Title: Re: Some audio stuffs
Post by: Black Tiger on November 06, 2015, 03:47:12 AM
So that adpcm player you posted a video of playing that Mega Man cover would be doable cpu-wise in an RPG then? It'd be a cool way to do snippets of voice acting in cinemas (which I assume are even less intensive) or for repetitive bgms.
It's crazy to think that ineficient sound alone in Air Zonk eats up at least a third of cpu resource when it throws around as much as it does compared to SNES and Genesis shooters.
Title: Re: Some audio stuffs
Post by: touko on November 06, 2015, 04:21:57 AM
Thanks tom for clarifying about the cpu used for PCM , i was not sure about the number of percent,this is why i deleted my answer for chris .. Of course i spoke only for PCM and my values are for PCM only .
Quote
It was at 33% when it had to reload the bit shifter (decompress the samples), which if I recall is every three samples or so.
i probably use the same method to compress samples . 1 sample in the first 5 bit of the 1st byte 1 sample in the first 5 bit of the 2nd byte and the 3th packed in the 3 last bits of the first byte, and the 2 last ones in the 2nd byte, in fact only the 3th sample needs to be shifted . Of course you lose 1 bit, but your sample is reduced by 33% ..
Title: Re: Some audio stuffs
Post by: Bonknuts on November 06, 2015, 04:30:14 AM
I found over the years that good game developers, don't necessarily produce the most optimal code or design - to put it nicely. I've attempted to understand the thinking and philosophy of Japanese programmers in the 80's and 90's, and I'm just at a complete loss. I know there are factors keeping them from optimizing and fine tuning every little thing, but as a programmer and people that I known as programmers - there's this idea, this desire, this drive - that you want to create the best/fastest/whatever code possible; you want to push something to its limits. I guess that's a cultural thing and that's not what motivated most Japanese programmers at the time (with exceptions of course. There are always exceptions).
I read an interview with one of the guys that worked with Nintendo to get 3D on the SNES (originally meant for NES - the MARIO chip), and how he ended up moving to Japan and working directly with Nintendo programmers and producers for a number of years. He mentioned that game developers, like Miyamoto, would often take a game back to ground zero - many times during its development. If that was the case, I can see how optimizing stuff would be a waste of time during the development cycle. But to me, that shows that the producers were simply dictating to the programmers rather than working with them. Like I said, I really don't know.
Quote
So that adpcm player you posted a video of playing that Mega Man cover would be doable cpu-wise in an RPG then? It'd be a cool way to do snippets of voice acting in cinemas (which I assume are even less intensive) or for repetitive bgms.
Yeah, but it doesn't save a whole lot space (although the final sample output quality is better).
There are a lot of things you can do with an traditional JRPG that you couldn't normally do with an action game. For instance, you don't need to run the game at 60fps. It doesn't really benefit from it. But imagine what you could do with essentially a 14mhz cpu (basically what it translates into; twice the cpu cycles per "frame")? You already know the limitations of some of the graphics on the PCE; mainly tile flipping and layer priority (different than parallax). For instance, you could do tile streaming engines, where not only would it solve the tile flipping issue - but you could also create unique sets of tiles on the fly by compositing small details (later gen SNES games use multilayer BGs as a single BG to do this). Sprites could be AND'd in realtime with masks to create priority on a per pixel basis (I did a routine that can do this at 2% cpu resource per 16x16 cell sprite). All kinds of graphic effects for the overworld. The same could be applied to battles, etc.
Title: Re: Some audio stuffs
Post by: Bonknuts on November 06, 2015, 04:35:32 AM
Thanks tom for clarifying about the cpu used for PCM , i was not sure about the number of percent,this is why i deleted my answer for chris .. Of course i spoke only for PCM and my values are for PCM only .
Quote
It was at 33% when it had to reload the bit shifter (decompress the samples), which if I recall is every three samples or so.
i probably use the same method to compress samples . 1 sample in the first 5 bit of the 1st byte 1 sample in the first 5 bit of the 2nd byte and the 3th packed in the 3 last bits of the first byte, and the 2 last ones in the 2nd byte, in fact only the 3th needed to be shifted . Of course you lost 1 bit, but your sample is reduced by 33% ..
AZ is using a full 33% for a single channel though. You have it down to 3-4% per channel, right?
Title: Re: Some audio stuffs
Post by: touko on November 06, 2015, 05:00:36 AM
Quote
AZ is using a full 33% for a single channel though. You have it down to 3-4% per channel, right?
Yes, 3/4% with banking, buffering,decompress and of course playing sample .
Even my first unoptimised pcm driver was far under 30%, may be 6/7%,i can not understand how coders could be satisfied with 30%.
Title: Re: Some audio stuffs
Post by: Sunray on November 06, 2015, 06:08:02 AM
Hello, my first post here.
What is the difference between HuC6280 and HuC6280A exactly? I've head different things like click reduction and panning fixes?
Title: Re: Some audio stuffs
Post by: Bonknuts on November 06, 2015, 06:13:06 AM
phy phx pha sta $1403 lda <$f1 bne .skip lda #$01 sta <$f1 cli tam #$02 pha tam #$03 pha tam #$04 pha tam #$05 pha tam #$06 lda #$31 tam #$02 inc a tam #$03 inc a tam #$04 inc a tam #$05 inc a tam #$06 jsr $4000 ;jumps to DDA and music routine pla tam #$06 pla tam #$05 pla tam #$04 pla tam #$03 pla tam #$02 stz <$f1 .skip pla plx ply rti This is just the intro and extro code (TIMER routine). It's ridiculous because none of that overhead is needed for the DDA streaming part. And yet, there it is.
To clear any confusion, music engine is tied to the TIMER interrupt and not the Vblank interrupt. But I think even an entry level programmer could see the issue here. All those bank mapping and saving, etc - none of it has anything to do with the DDA sample and the bank it comes from. And it's mapped every time @ 6991khz even if a sample isn't playing.
Title: Re: Some audio stuffs
Post by: touko on November 06, 2015, 06:24:17 AM
Quote
Touko, this should give you an idea.... ;_;
:shock: LOL, it's crazy how it's very bad coded,i understand why it takes 30% :mrgreen:
Title: Re: Some audio stuffs
Post by: Bonknuts on November 06, 2015, 06:30:59 AM
Yeah, it's bad. Not just that, but the Hsync routine is a mess as well. I'm surprised this game isn't in perma slowdown.
Title: Re: Some audio stuffs
Post by: touko on November 06, 2015, 06:40:05 AM
I found over the years that good game developers, don't necessarily produce the most optimal code or design - to put it nicely. I've attempted to understand the thinking and philosophy of Japanese programmers in the 80's and 90's, and I'm just at a complete loss. I know there are factors keeping them from optimizing and fine tuning every little thing, but as a programmer and people that I known as programmers - there's this idea, this desire, this drive - that you want to create the best/fastest/whatever code possible; you want to push something to its limits. I guess that's a cultural thing and that's not what motivated most Japanese programmers at the time (with exceptions of course. There are always exceptions).
I read an interview with one of the guys that worked with Nintendo to get 3D on the SNES (originally meant for NES - the MARIO chip), and how he ended up moving to Japan and working directly with Nintendo programmers and producers for a number of years. He mentioned that game developers, like Miyamoto, would often take a game back to ground zero - many times during its development. If that was the case, I can see how optimizing stuff would be a waste of time during the development cycle. But to me, that shows that the producers were simply dictating to the programmers rather than working with them. Like I said, I really don't know.
I don't have the time (or interest) to write a long article to try to explain the history and the different development philosophies over the last 30 years ... but if you hang around the right bars surrounding GDC or E3 you'll probably find some old-timer to tell you about the realities of the industry.
Most programmers like a beer, and free beer definitely helps lubricate a discussion! :wink:
With your personal passions and capabilities, a big company would put you on the Engine team, where your talents would be used best.
In a small company you'd probably be a lead-programmer.
Either way ... you'll find that it's usually not cost-effective to over-optimize things, no matter how programmatically "beautiful" it is.
Having enough experience to know where to draw that line is something that usually comes with time ... and with working too many late nights in a row in order to hit a deadline.
When you're an amateur (or retired), then you get the freedom to do things however you like, and to spend as much time as needed to wring every-last-cycle out of a particular piece of code. As you already know, it's fun! :)
Yeah, it's bad. Not just that, but the Hsync routine is a mess as well. I'm surprised this game isn't in perma slowdown.
And that's kind of the point ... in a lot of companies, "not-actually-causing-a-problem" really is "good-enough" when it comes to shipping a project.
When if comes to hitting a deadline, it's often cheaper-and-easier to just remove an enemy sprite or a background effect, rather than get a programmer to rewrite their code to make it faster.
Not all programmers are "great" ... and sometimes you'll find a "really-not-great" one on a team, particularly in the larger teams that some of the Japanese developers used.
Title: Re: Some audio stuffs
Post by: Black Tiger on November 06, 2015, 07:03:20 AM
Considering the reception the game has enjoyed (including being technically impressive to most people), Air Zonk really was good enough as it is. But it's fun to imagine what could be possible on PCE if a team really pushed the hardware efficiently.
Title: Re: Some audio stuffs
Post by: touko on November 06, 2015, 07:41:06 AM
@elmer: you're right, and i agree with you .. But the code that bonk showed us, is really a pure shit, even with a deadline and commercial obligations,the reality is here .
Quote
Air Zonk really was good enough as it is
Of course, and it's the impressive parts IMO, nobody has thinked, how the code was bad when they were playing with this game(in fact it's just the opposite),i'am really surprised by the amateurism .
Title: Re: Some audio stuffs
Post by: Bonknuts on November 06, 2015, 08:17:03 AM
I don't think my XM PCM engine should really be compared to the average PCE game sound engine. Not that what I've done is amazing (it's not; anyone who can count cycles and optimize could do this - there's nothing revolutionary in my approach), it's just really tightly optimized. It looks more complicated that it is, in the source code, because of how it is made compatible for hucards - and PCEAS makes relocatable code a pain (this is where an intermediate object format would be great - linker). But it's just self-modifying code (nothing some PCECD games didn't do).
Quote
When you're an amateur (or retired), then you get the freedom to do things however you like, and to spend as much time as needed to wring every-last-cycle out of a particular piece of code. As you already know, it's fun! :)
I think that's one of the really fun things about coding on these old consoles. Seeing what they could really do. I think it's safe to say that the most popular systems of their era, tend to have thee examples of games that push the system just because of the whole dynamic of competing developers, pushing that bar. Maybe the other half of coding for these old consoles is just to put out something people will want and play. Maybe even fulfilling that childhood dream of make of game for your favorite system. But the PC-Engine is kind of a gold mine for exploring what can be done with it. Sometimes the approaches are extreme, but it's still fun.
Quote
Having enough experience to know where to draw that line is something that usually comes with time ... and with working too many late nights in a row in order to hit a deadline.
I always try to keep that in mind. It's all too easy to criticize after the fact. But there is always that part of me that feels; if you going to create something, present something, people are only going to see the end result. You can't go back fix it after the fact. And no amount of excuses (valid or not) will ever change the experience and impression of that presentation - what people got out of it. Trying to get a feel for where to draw that line, is difficult in my opinion. Especially when you can see nothing but promise and capability. Not just with coding, but with any sort of creation (literary works, art, music, etc). Finding balance with personal creations and being part of a team or company that sets restraints or limitations - it never leaves a completely satisfying feeling. I guess that's where hobbies are supposed to come in and fill that gap?
Quote
When if comes to hitting a deadline, it's often cheaper-and-easier to just remove an enemy sprite or a background effect, rather than get a programmer to rewrite their code to make it faster.
Sometimes, there are examples where companies should have taken that approach - lol. Instead, games flickered beyond belief or were plagued with slowdown (no console in specific). To me, that's a higher level design decision - the producer or managers ultimate responsibility.
Quote
But the code that bonk showed us, is really a pure shit, even with a deadline and commercial obligations,the reality is here .
Yeah. I try to limit my criticisms to stuff that's more on the extreme side of things. For PCE, it's usually sprite optimization - or rather approaching the system like an arcade machine with lots of sprite pixel line bandwidth.
Quote
Most programmers like a beer, and free beer definitely helps lubricate a discussion! :wink:
I don't know anyone in real life that codes. And if I did, it probably wouldn't be for old consoles. A beer and talking shop sounds great!
Title: Re: Some audio stuffs
Post by: ccovell on November 06, 2015, 11:30:33 AM
phy phx pha ... ply rti This is just the intro and extro code (TIMER routine). It's ridiculous because none of that overhead is needed for the DDA streaming part. And yet, there it is.
This looks to me like he's trying his darndest to make the game crash-proof in all situations -- for example, if you store MPR shadows somewhere upon interrupt, they could get overwritten when a second interrupt happens. MPRs on the stack might be the fastest way when you have 2 or more simultaneous asynchronous interrupts going on. (Although I didn't look at the rest of the Air Zonk code, so I dunno...)
Title: Re: Some audio stuffs
Post by: Bonknuts on November 06, 2015, 01:37:53 PM
I don't think it's testing for crashes (stack overflow). There's an internal state flag that prevents the routine from being called again, once CLI is executed inside it. So it can't be called inside itself.
It's mapping banks for the main music routine to use. It's definitely a lot of banks. Maybe some of the samples are there as well (it doesn't have a lot of samples in the game - maybe it fits within 16k of that block). But it's definitely a large block map procedure.
But my point is that the music routine only needs that support (banks) at the most - twice per frame. I.e. the music engine might run a song at 76hz instead of 60hz so you'll get a double call in a single frame once in a while. But that overhead is being called 116.7 times per frame, since the DDA routine is also using the timer interrupt. All they needed to do what prioritize for the DDA and map what's needed for what needs it, when it needs it. On the one or two instances it happens per frame, then map in that support.
It's only one sample stream playing at a time. You only need to map in one bank for that. Maybe two if the tiny DDA routine really needs to be at $4000, but it should have been able to fit into the last bank. I dunno - priority and all that sort of thing.
Title: Re: Some audio stuffs
Post by: touko on November 06, 2015, 08:05:47 PM
Quote
Yeah. I try to limit my criticisms to stuff that's more on the extreme side of things. For PCE, it's usually sprite optimization - or rather approaching the system like an arcade machine with lots of sprite pixel line bandwidth.
i can understand that using the largest sprites size (32x64) for exemple is the easiest way(DD2 and strider did that) to avoid using metasprites,but i'am for a minimum of clean and/or logical coding, especially by a (supposed) professional . There is a big marging between crazy ass optimised code, and crazy ass unoptimised one,and i did not expect that coders spend many hours optimizing their routines,but definitively not at this point .
Title: Re: Some audio stuffs
Post by: Bonknuts on November 08, 2015, 10:52:09 AM
Touko: What if I said that I could give you 8 PCM channels at 6bit depth, each with full volume control, driven at 7khz... all with a total cpu resource requirement of 21.5%?
Btw, those 8 PCM channels still leaves 4 regular PCE audio channels remaining (a total of 12 audio channels). What would you do with all those sample channels? Mind you, they would be fixed frequency (no pitch bending). Also, those PCM channels would be mono. But the regular PCE channels would still be stereo.
Title: Re: Some audio stuffs
Post by: elmer on November 08, 2015, 01:04:21 PM
8 PCM channels? That fast? :shock: ... Cool! :D
Title: Re: Some audio stuffs
Post by: touko on November 08, 2015, 07:22:56 PM
Quote
What if I said that I could give you 8 PCM channels at 6bit depth, each with full volume control, driven at 7khz... all with a total cpu resource requirement of 21.5%?
I will answer ,it's you manfred trenz !! ;-)
It would be awesome of course .
Title: Re: Some audio stuffs
Post by: Bonknuts on November 09, 2015, 05:07:13 AM
Quote
it's you manfred trenz !! ;-)
Manfred Trenz!?!? But.. I don't have a beard ;>_>
So now I just need to deliver on the goods. I've written it all the routines, I just need make a split table and a volume table.
Quote
8 PCM channels? That fast? :shock: ... Cool! :D
I didn't think it was a big deal, because they aren't frequency scaled like fancy mod/xm channels. I always though it was apparent that the PCE could soft mix channels pretty fast, so I never really bothered with showing it off. But the other day, I was reading over the comments of single channel ADPCM demo I posted (I didn't write that demo, I just optimized/modified it to play faster; mednafen author wrote it).. and people seem to think they're impressive. The main point of those demos wasn't high frequency, high resolution PCM playback - but to demonstrate realtime decompression capabilities of the PCE (4bit storage for 10bit output is pretty decent savings). Then it dawned on me a couple of days ago.. I guess people really aren't aware of capabilities of the PCE to do soft mixed streaming samples. It's as if the 65x core were design to do this - lol. Super fast indexing, direct memory access, and look-up tables are the ingredients in the magic elixir for the 65x. Sprinkle a little self-modifying code and voila - power.
Off topic of this, I was messing with frequency ranges from 7khz to 15.3 khz (256 samples per frame). And right about 9.5khz there is a sharp increase in clarity. The difference from 7khz to 9.5khz is bigger than any difference above it. Well, in response to this one clip. The Gameboy Advance "Sappy" driver, the driver Nintendo provided in the devkits, had 8 frequency scaled PCM channels feeding an 8bit DAC. There's two 8bit DACs, but if you're doing stereo it's still 8bit. The playback rate of that player is ~13khz. Advance Guardian Heroes on the GBA uses ~7.88hz playback. It kind of puts a perspective on things.
All this assumes the direct write to DDA port method. I haven't explored abusing the waveform buffer.
I'm also toying with the idea of maybe abusing some sort of bias into the analog signal, to create a lower frequency tone. Something bass-ish. An example would be if you ran a timer interrupt that always feed a DDA channel (even line zero data), but assuming the DDA channel really does respond to a ceiling of 3.58mhz, you could write two "pulse" values 40 cycles before the actual DDA sample. That pulse would exist at 178.9khz, changing at a rate of 7khz. Not really sure how it would sound, or how much of an impact it would have in terms of amplitude. Might not be worth the overhead, even if it is small. It needs testing. If it does work, it'll be one of those things that only works on the real system (unless an emulator can respond to DDA writes that fast).
There are just so many different ways to create audio stuffs on the PCE. It's kinda like being a kid in a candy store. Which one to choose?
Title: Re: Some audio stuffs
Post by: touko on November 09, 2015, 05:43:05 AM
Quote
There are just so many different ways to create audio stuffs on the PCE. It's kinda like being a kid in a candy store. Which one to choose?
Ahahah, too many ideas, and no enough time .
Quote
Manfred Trenz!?!? But.. I don't have a beard ;>_>
Lol true, but beard is not the most difficult skill to have . ;-)
Better quality for samples means more space in rom eaten,it's not a big deal if you have a 20MB(or more) card or AC, but definitively with classic ones.
Title: Re: Some audio stuffs
Post by: Bonknuts on November 09, 2015, 06:23:20 AM
Hmm.. this thread is soo off topic. I'll continue audio stuffs in the other pin'd thread.
For those that can test the rom that I'll provide a link for.. just give me a few days. :)
Title: Re: Some audio stuffs
Post by: ccovell on November 09, 2015, 12:31:32 PM
The Gameboy Advance "Sappy" driver, the driver Nintendo provided in the devkits, had 8 frequency scaled PCM channels feeding an 8bit DAC. There's two 8bit DACs, but if you're doing stereo it's still 8bit. The playback rate of that player is ~13khz. Advance Guardian Heroes on the GBA uses ~7.88hz playback. It kind of puts a perspective on things.
Apparently, the GBA DAC converts the PCM channels through PWM (at 65Khz) which degrades the sound quality *lots*.
I speak for myself, but one of the reasons not a lot of people hit the sample hardware (& make trackers, etc.) on the PCE is complete lack of musical know-how.
Title: Re: Some audio stuffs
Post by: Bonknuts on November 09, 2015, 03:34:05 PM
Quote
one of the reasons not a lot of people hit the sample hardware (& make trackers, etc.) on the PCE is complete lack of musical know-how.
You mean music composition?
Title: Re: Some audio stuffs
Post by: ccovell on November 09, 2015, 04:15:32 PM
Not even composition -- if a person doesn't know how musical time signatures work, note lengths, etc. etc. then he wouldn't even know how to make an optimal music format or player. You know, the stuff that aids in composition.
Title: Re: Some audio stuffs
Post by: touko on November 09, 2015, 08:19:20 PM
Quote
on the PCE is complete lack of musical know-how. if a person doesn't know how musical time signatures work, note lengths, etc. etc. then he wouldn't even know how to make an optimal music format or player.
i agree with you chris,i'am able to do a sfx driver(the more easy part), but i'm not able to create any sfx(except white noise) from scratch,music (driver and compos) is simply out of questions for the reasons you said .
Title: Re: Some audio stuffs
Post by: elmer on November 10, 2015, 04:38:13 AM
Not even composition -- if a person doesn't know how musical time signatures work, note lengths, etc. etc. then he wouldn't even know how to make an optimal music format or player.
I totally agree with this.
When I wrote my first music driver, I started off completely ignorant of all of those things, and it was only because I was working directly with a musician, and basically coding to his design requests, that I began to get even a simplistic understanding of how music was put together.
If I hadn't been working with that guy, I wouldn't have know where to start.
As a programmer, I still don't understand how musicians think and how they work their magic. :oops:
Quote
You know, the stuff that aids in composition.
IMHO this is the critical part these days. To be productive, the musician must be given a way to easily edit the music that gives them rapid feedback.
There is plenty of cheap software to create music now, and I suspect that anyone working on a "new" driver needs to tie into (and extend?) some existing format that has a mature and comprehensive editor ... or else it may see little use. Most folks just don't like to have to learn completely new stuff in order to use something.
Title: Re: Some audio stuffs
Post by: Bonknuts on November 10, 2015, 02:13:42 PM
Depends on the musician. Some of the competing chiptune musicians nowadays want ultimate flexibility in sound design and aren't too afraid to get their hands a bit dirty.. in the mix of it (pun intended).
But I think an interface that allows both a simplistic and easy approach, at the same time while also offering a complex side for more flexibility when the user gets acquainted with the setup - is the best approach. Nothing sucks more than, "oh! I love this engine but... if I could only do this.." Well, almost. I guess there could be worse things.
Title: Re: Some audio stuffs
Post by: Bonknuts on June 26, 2016, 10:46:04 AM
Ok guys, I need some testers to test this out on the real hardware: http://www.pcedev.net/audio/SamplePlayer/test_sm_note_stereo.zip
Let it cycle through the high octaves, and then wrap around to octave one. You can stop it at octave three on the wrap around.
I just want to make sure it works on other real hardware. This is just a single channel and note incrementing. I have other tests coming up with finestep and multiple channel stuffs.
Title: Re: Some audio stuffs
Post by: touko on June 27, 2016, 01:01:38 AM
I'll test asap on my sgx .
EDIT: tested ,it works fine, there is some noise on the sample playback, but the pitch change works very well,but sound is only on the left speaker .
Display is ugly thought, the text is distorded .
Title: Re: Some audio stuffs
Post by: Bonknuts on June 27, 2016, 12:14:46 PM
Cool. Thanks Touko.
I've been rewriting almost all the interface code to the PCM driver, so I need to retest a lot of things. Also moving stuff around, and making it as flexible as possible.
I also have some print string libs that I'll probably make public. I haven't really seen any for PCE assembly (public).
Title: Re: Some audio stuffs
Post by: Bonknuts on June 28, 2016, 06:12:45 AM
Hey guys, I'm just writing up the doc/usage file so I can release this MOD-ish driver.. but I'm stuck as what to name it.
Any ideas? Hu-MOD? Hu-XM? <- I picked XM in that example because the audio driver uses linear steps in frequency scale instead of period based scaling.
Title: Re: Some audio stuffs
Post by: elmer on June 28, 2016, 06:58:25 AM
Any ideas? Hu-MOD? Hu-XM? <- I picked XM in that example because the audio driver uses linear steps in frequency scale instead of period based scaling.
HuTrack??? :-k
I'd suggest not calling it "XM" anything unless it's actually going to play existing XM mod files.
Title: Re: Some audio stuffs
Post by: Bonknuts on June 28, 2016, 07:11:26 AM
Yeah, the XM thing is pretty misleading. HuTrack is better than HuMOD, too.
Title: Re: Some audio stuffs
Post by: Necromancer on June 28, 2016, 08:05:20 AM
HuEargasm?
Title: Re: Some audio stuffs
Post by: johnnykonami on June 28, 2016, 08:59:58 AM
Husic.
Title: Re: Some audio stuffs
Post by: Bonknuts on June 28, 2016, 09:04:27 AM
HuSic is already used, IIRC.
Title: Re: Some audio stuffs
Post by: spenoza on June 28, 2016, 02:28:08 PM
I think HuTrack is the best of the options listed, though HuMod also makes sense.
Title: Re: Some audio stuffs
Post by: Bonknuts on June 28, 2016, 02:29:44 PM
Well, I didn't name it yet. But here's the first public release: http://www.pcedev.net/audio/SamplePlayer/driver_package_v_1_2_0.zip There's a demo rom already assembled, if you want to hear a quick sample.
Hopefully everything's cleaned up (nice and neat looking). The README file is like 19 pages long. Took me forever to write that damn thing. If anything isn't clear in the README, post your questions here.
Title: Re: Some audio stuffs
Post by: johnnykonami on June 28, 2016, 03:45:50 PM
Dangit! But you did and all the glory should go to you now. Go get crackin' on that PCE only video site!
Title: Re: Some audio stuffs
Post by: Bonknuts on June 29, 2016, 05:14:55 AM
What about Hu + demon name? Or something ancient. HuCules? HuCample? HuStream? HuBit?
Title: Re: Some audio stuffs
Post by: Bonknuts on June 29, 2016, 02:01:24 PM
I found a couple of XM files that should be easy to play (very minimal FX to implement). Something to show the driver off. No converter needed; just gonna parse the XM file (minus the samples) inside PCE code. Well.. technically they're MODs converted to XM - but whatever.
Btw, no one read the readme.txt file? No issues?
Title: Some audio stuffs
Post by: esteban on June 29, 2016, 10:31:17 PM
HuLU HuMOAR HutuTUTSI HuMANITY HuMANATEE HuTREE HuPALM HuBOMB HuNAM 1975
HuGNU? HuZOO HuBAT HuBALZAC
Title: Re: Some audio stuffs
Post by: ccovell on June 30, 2016, 12:05:15 AM
HuGH Laurie HuGE Testicles Hu's Afraid of Virginia Woolf? HuZero HuGuenots HuIS Ten Bosch HuWLETT-Packard HuOOL'S Gold Hu! I have the Vapours!
Title: Re: Some audio stuffs
Post by: Bonknuts on June 30, 2016, 04:15:07 AM
Hubert HuEncy Jones HuIckBooksPro Xtree Hu-Gold HuGo Huey Potter and the Sorcerer's stone HuDontKnowMe! HuBe Or Not To Be HuYyyuuuggeee HuAppy Days HuAula (Paula) HuKuu Nest HuMany Bits JB HuArold (Cause I'm murdering it. Whhaaa.....)
Non Hu names TurboMOD TurboXM TurboMX TurboDriver TurboDriverZL ( I have no idea)
Title: Re: Some audio stuffs
Post by: Bonknuts on June 30, 2016, 04:19:16 AM
Title: Re: Some audio stuffs
Post by: touko on July 01, 2016, 08:54:34 PM
Quote
Hu2 ?
:lol: ,nice .
Title: Re: Some audio stuffs
Post by: Bonknuts on July 03, 2016, 05:33:54 AM
Ok, I'm making a fundamental change to the timing and update mechanism of the driver. The timings are much more relaxed in the next release (no more 262 vs 263 line per frame nonsense/worry). And the over head is less than 1% cpu resource. I'm also going to add a few more macros, as well as just a subroutine call information for bypassing macro usage (ran into this problem with the XM player I'm writing, outputting to this driver).
Title: Re: Some audio stuffs
Post by: Bonknuts on July 03, 2016, 12:18:30 PM
Alright.. I wrote a quick simple XM player for PCE. Here a pack of three files (just the roms) http://www.pcedev.net/XMPlay/XMPlay_Pack1.zip
This is just to demonstrate interfacing the PCM Driver with a music engine. Note: The samples are converted as is (no post processing on them), so some of them are a little rough.
Also, if anyone has the free time - recorded it from the real console and post here :D
FYI: If you want to run it in an emulator, that's fine too. But I'm not interested in emulator recordings (it should be slight softer on the real system because of entering the filter threshold).
Edit: Fixed broken link.
Title: Re: Some audio stuffs
Post by: Bonknuts on July 03, 2016, 04:50:25 PM
Another test pack: http://www.pcedev.net/XMPlay/HuXMPlay_Pack2.zip Fletch and Axel_f definitely sound better on the real hardware.
These packs are just to show off some stuffs. It's clear that some samples are getting crushed by played above 2x the 7khz driver. I didn't prep for that. More of a test to see which samples sound decent as is.
The filtering effect should work in favor of the real hardware once I get a 15.6khz version up and running.
Title: Re: Some audio stuffs
Post by: Dicer on July 03, 2016, 05:46:02 PM
I'll give both packs a spin on real deal hardware tomorrow, looking forward to hearing it...
Title: Re: Some audio stuffs
Post by: Bonknuts on July 04, 2016, 07:54:08 AM
I fixed a bug in the driver for channels 1-3 that have looping points (it would update based on channel 0 data, for the other channels - which could go into an infinite loop on the interrupt routine). Gonna move the update processor inside the last TIRQ call, so timing won't be a problem. Vblank interrupt still resync's the TIMER though. I also found that XM/MOD files tend to have the looping data inside the wavefile itself ("smpl<"), so I'm gonna update wav2sixbit util to use this. I release those updates soon.
I'm gonna make official thread for the PCM drivers (yes, there will be multiple versions), which I'll update when they mature. So this thread is still for discussing WIP PCM stuffs/concepts.
As of now, since the first PCM Driver incarnation seems to be working quite well - I'm gonna start the 15.6khz version. The approach is a little different. Here's a basic driver setup:
;42 cycles for overhead (includes INT call itself)
;29+42 = 72 * 262 = 18,864 or 15.8% cpu
.PCMDriver dec <DriverCnt ;6 beq .reload ;2
.re-entry ldy <Bffr_IY ;4 inc <Bffr_IY ;6
;18
stz $800 lda buffer1,y sta $806
lda #$01 sta $800 lda buffer2,y sta $806
lda #$02 sta $800 lda buffer3,y sta $806
lda #$03 sta $800 lda buffer4,y sta $806 ; 66 cycles
; 66+18 = 84 ; @256 times = 21504 cycles or 18% cpu resource
; Note: 21.5% for 6 channels.
ply ;4 pla ;4 rti ;7
.reload dec <CounterTableIY bpl .NoResetIY lda #$5 sta <CounterTableIY .NoResetIY ldy <CounterTableIY lda .CounterTable,y sta <DriverCnt jmp .re-entry
.CounterTable .db 43,44,44,43,44,44 ^- Just one example. With the indirect jump, you can do all kinds of setups.
So the base setup, no Hint FX, is 30% play 4 channels at 15.6khz. Of course, this doesn't include the frequency scaling. That's all done outside this routine. This is just one of many types of 15.6khz setups.
If you notice, the channel select operates take up some timing. That's unfortunate as they really didn't need to implement that type of system (they could have mapped all registers to their own unique addresses). But what that does mean, is that doing a 10bit paired channel output won't be much more resource (probably nearly the same). Just that it wouldn't be stereo, but you'd have 4 regular PCE channel that are stereo.
The same setup, but with 10bit paired would save 34 cycles over head per sample (two samples) initially. But software volume costs +5 cycles, and mixing costs +7. So 48 cycles total overhead for soft channels (10bit method), but 34 cycles saved, so +14 cycles more or 3% more cpu resource. Mono, but 4 frequency scaling channels at a higher bit depth (6bits per channel, or 7bits with a little bit more resource).
Anyway, so 30% for the "driver" part. If I can frequency scale four channels in 20% cpu or less (which should be doable), then I'll have hit my mark: 50% total cpu resource to playback 4 channels at 15.6khz. The quality should jump up dramatically. On the real system, there should be even more of a filter effect too since the playback rate will be higher. And on some emulators, it won't sound so good (they don't expect that high a DDA playback rate, and so will miss sample writes, etc). Ootake had a crappy artifact in DDA writes even at 7khz - did they fix that? As per usual, mednafen shouldn't have a problem.
Title: Re: Some audio stuffs
Post by: Dicer on July 04, 2016, 08:18:08 AM
Burn Rubber: Nice track, sounds appropriately retro Destructive: Misleading title, I wanted to construct not destruct Night Train: Really like this one, should be in a beat em up city level, and vocals nifty.
Axel F: well, makes me want a crazy frog bros OBEY title, maybe with pizza tossing Empty Spaces 2: Not my scene, a bit too down tempo but still nice work Fletch: Chevy chase would be proud Out on a limb Fast/Slow: I actually prefer the down tempo version, very un-typical of me.
Now get me some 2-unlimited or ultra BPM mixes up in here and I'll be a happier camper.
Title: Re: Some audio stuffs
Post by: Bonknuts on July 04, 2016, 09:23:04 AM
Find some decent 2 unlimited mods... then we talk.
Someday, I want to do a PCE version of this demo:
Title: Re: Some audio stuffs
Post by: Dicer on July 04, 2016, 10:22:48 AM
And because I've always like this one http://janeway.exotica.org.uk/release.php?id=50127 BLUEBOXING
Title: Re: Some audio stuffs
Post by: ccovell on July 04, 2016, 12:26:13 PM
If it helps -- probably not -- here is my writing loop in Old is Beautiful for playing 8-bit PCM. I do double the channels (4) just to get a louder overall output.
Sample_Loop: bbs0<samp_interrupt,.no_sample_play bbr0<samp_on,.no_sample_play .samp_loop: smb0<samp_interrupt;Stop player from entering twice lda[sampadd] beq.sample_end_marker tax lsra lsra lsra;divide by 8! sax and#$07;top 3 bits ldy#3 sty$0800 ;chan 3 sta$0806;Save sample!! dey sty$0800 ;chan 2 sta$0806;Save sample!! dey sty$0800 ;chan 1 stx$0806;Save sample!! stz$0800 stx$0806;Save sample!! incw<sampadd rmb0<samp_interrupt;Stop player from entering twice
.no_sample_play: rts .sample_end_marker: rmb0<samp_on;no more samples! rmb0<samp_interrupt;Stop player from entering twice rts
Title: Re: Some audio stuffs
Post by: Bonknuts on July 05, 2016, 05:26:38 AM
ccovell: How did I not know about this demo!? Ok, I messed with that mode (7.16mhz with no h-filter) for years, but I could never figured out how to calculate the color values. What program or process did you use?
Title: Re: Some audio stuffs
Post by: Bonknuts on July 05, 2016, 07:18:01 AM
So I'm working on reducing the frequency scaling routine for the VDC int version. Here's the simple conversion of the timer one to it:
But that's 42 cycles per channel: 42*246*4 = 43008 cycles or 36% cpu resource. Easy to implement, but too high.
I need to get that cycle count down into the 20's.
My two option are precalc code paths (using jump tables to keep the size down) or bit mask (they're long, but shouldn't eat too much memory; aka lsr mask, bcc skipsample).
dex ;2 bne .loop ;4 That gives 64 samples. So a reset of some addresses 4 times total (4*64 = 256 samples). It's not bad. Base is 28 cycles a sample. The second part happens every 8 samples, so that overhead is 6/8 = .75 cycles. And the overhead every 64 samples is less than 1 cycle per sample. So I'll round it up to 29 cycles per sample. That's 4*29*256 = 29696 cycles or 25% cpu resource.
Better than 36%, but not quite the less-than-20% mark I'm looking for. I think I might have to do code paths to get it lower...
Title: Re: Some audio stuffs
Post by: ccovell on July 05, 2016, 12:14:58 PM
I've asked myself that question, too. :-| Maybe people were preoccupied at the time.
Anyway, depending on the odd/even phase of the VCE at the time that you make it static, dithered patterns consistently give either a usable red (verging a tiny amount towards orange) channel over 15 shades, or a cyan (harder to wrangle because it is 2 RGB channels combined.) So: (http://chrismcovell.com/images/OldIsBeautiful_expl.jpg)
Another test demo: http://chrismcovell.com/data/OldIsBeaut-Test.zip
I didn't use any special tools; removing the R channel from 24-bit pictures is good enough, and the R can be remapped separately to greyscale, or some ramped red/grey; the remaining G&B can be remapped down to PCE BG palettes, since there are now 64 colours possible per tile that have to be reduced.
Title: Re: Some audio stuffs
Post by: Bonknuts on July 06, 2016, 09:23:15 AM
Ahh ok. So remove the red channel (or crush it near completely down) because the shift (Y to chroma interference) will re-introduce the red back in? I could never figure that part out (I did artifact colors in that mode with dot crawl filter off, but could never figure out how to calculate the colors).
I ran it on my new 4k HD set and it looks perfect! So even the newer sets with their fancy digital processing filters, couldn't separate Y from C in that res mode. The high color part is very nice, but transparency effects makes sooooooooo many new things possible for demo scene stuff! This is pretty awesome Chris :D
So I can just use my RGB to YUV converter, crush the R-Y channel, and convert back?
Title: Re: Some audio stuffs
Post by: ccovell on July 06, 2016, 12:32:12 PM
I don't know what the effect is if you work in YUV colour space, but one of the side effects of this effect is that the Green channel gets slightly muted... you can see that from Yellow to Green at the far left, there is some blue mixed in, which should never be there. But, ah, well.
Title: Re: Some audio stuffs
Post by: Bonknuts on July 09, 2016, 12:34:35 PM
Ok. I promised earlier this year that I would do a 12 channel driver for PCM. 4 regular channels and 8 PCM channels.
So 9% cpu resource for the driver and 12% cpu resource to mix 8 channels into a single buffer stream. 4 of the channels have direct volume control, and the second set of 4 channels are direct non-changeable volume (max volume).
Due to optimizing for less amount of cpu resource, the sample format is arranged in a non standard format. There's a little bloat too: and extra 720bytes per second. Not too bad, considering I use 6bit PCM for each channel. I could have done 7bit, but it wasn't optimal processing wise for all 8 channels.
21% cpu resource total for 8 PCM stream playback out of 12 channels.
The problem I have now.. is how to demo all 8 PCM channels at once.. along with 4 regular PCE channels.
Note: All PCM streams are signed 2's compliment. I could technically speed it up be keep all PCM format as non-signed format. It'll still mix, but it will create a dynamic DC offset IIRC. Might not be noticeable.
Title: Re: Some audio stuffs
Post by: Bonknuts on July 09, 2016, 01:04:57 PM
Since a few other arrangements of straight PCM channels use the same basic format, I have some resource numbers for those too.
All have 4 regular PCM channels.
4 PCM channels @ 6bit with volume control: 16% cpu resource.
4 PCM channels @ 7bit with volume control: 18% cpu resource.
Title: Re: Some audio stuffs
Post by: Bonknuts on July 11, 2016, 10:10:15 AM
If it helps -- probably not -- here is my writing loop in Old is Beautiful for playing 8-bit PCM. I do double the channels (4) just to get a louder overall output.
Did you do an 8bit vs 10bit paired channel setup to save 2cycles per sample?
(edited)
Title: Re: Some audio stuffs
Post by: ccovell on July 11, 2016, 01:13:29 PM
I wanted to get better than 5 bit audio, but saving on space was the most important consideration, followed by "unpacking" speed, so 8-bit linear was what I chose. 8-bit is also easiest to edit in sample editors.
I calibrated the output (ie: how much to lower the volume of the lower 3 bits' channel) using an 8-bit sawtooth wave and an oscilloscope. ex:
Title: Re: Some audio stuffs
Post by: Bonknuts on July 11, 2016, 05:04:54 PM
Yeah, you did the same thing but calculated it at 1/4 for the second part. It saves two cycles since all you needed was and #$07 instead of two ASL's.
7bit PCM channels: I've seem to have run into a problem with my mixing routine. I was trying to mix without sign extending every sample before the add. This worked for the final 8bit + 8bit (detecting and branching code), but not the 7bit+7bit leading into them.
So I'm gonna switch over to unsigned samples and just add them. It works, but it doesn't look as pretty (should sound identical). I mean, I've done this on the PCE with regular channels and it was fine (made all waveforms in the upper 10-1f range only). This means I need to rebuild a few LUTs...
Title: Re: Some audio stuffs
Post by: elmer on July 12, 2016, 03:49:15 AM