RIP to BT Garner of MindRec.com... BT passed away early 2023 from health problems. He was one of the top PCE homebrew developers and founder of the OG Turbo List, then PCECP.com. Condolences to family and friends.
IMG
IMG
Main Menu

Some audio stuffs

Started by TurboXray, 10/31/2015, 02:39 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

johnnykonami


TurboXray

HuSic is already used, IIRC.

spenoza

I think HuTrack is the best of the options listed, though HuMod also makes sense.

TurboXray

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.

johnnykonami

Quote from: TurboXray on 06/28/2016, 04:04 PMHuSic is already used, IIRC.
Aww, I thought I was clever!

elmer

Quote from: johnnykonami on 06/28/2016, 10:45 PMAww, I thought I was clever!
You should have suggested "HuTube"!  :wink:

johnnykonami

Quote from: elmer on 06/28/2016, 10:55 PM
Quote from: johnnykonami on 06/28/2016, 10:45 PMAww, I thought I was clever!
You should have suggested "HuTube"!  :wink:
Dangit!  But you did and all the glory should go to you now.  Go get crackin' on that PCE only video site!

TurboXray

#57
What about Hu + demon name? Or something ancient.
HuCules? HuCample? HuStream? HuBit?

TurboXray

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?

esteban

#59
HuEY

HuCLEUS
HuBIT
HuWAVE
HuSINE
HuCOSINE
HuLOG
HuLOAF
HuLOAD
HuPLAY
HuGOSUB

HuNAN
HuYORK
HuKRAINE
HuCHARD
HuCABBAGE
HuBABBAGE
HuHEFNER
HuME?
HuMANCHU

HuLU
HuMOAR
HutuTUTSI
HuMANITY
HuMANATEE
HuTREE
HuPALM
HuBOMB
HuNAM 1975

HuGNU?
HuZOO
HuBAT
HuBALZAC
IMGIMG IMG  |  IMG  |  IMG IMG

ccovell

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!

TurboXray

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)

TurboXray


elmer

Quote from: esteban on 06/30/2016, 05:31 AMHuMANCHU
Ooooo ... I love this one. He always ended each move with "The World Shall Hear From Me Again!", perfect for an esoteric tracker!

Has anyone suggested "HuTune", "HuLoop" or "HuScream" yet?

esteban

Quote from: TurboXray on 06/30/2016, 11:19 AM
Quote from: esteban on 06/30/2016, 05:31 AMHuCHARD
Jean-Luc ?
I wish!

I was thinking arugula/lettuce family.

I thought maybe cabbage would be close enough, since HuTABAGA (rutabaga) was too silly, even for me.

:)
IMGIMG IMG  |  IMG  |  IMG IMG

NecroPhile

HuRMONY
Horton Hears a Hu

Quote from: TurboXray on 06/30/2016, 11:15 AMHuey Potter and the Sorcerer's stone
:lol:
Ultimate Forum Bully/Thief/Saboteur/Clone Warrior! BURN IN HELL NECROPHUCK!!!

touko

#66
Husux
Huthatgirl
Huareyou

QuoteHuAppy Days
:D

TurboXray

huLala
HuMelette du fromage
Hu La Vie
HuSacrebleu!
HuVoila

touko

Ahahah this is good ;-)

esteban

#69
HuLot'sHoliday

---French HuWAVE---
HuCarabiniers
HuLeFou
HuMépris
IMGIMG IMG  |  IMG  |  IMG IMG

NecroPhile

So many funnies.  :lol:

Hu Re Mi Fa So La Ti Hu
Ultimate Forum Bully/Thief/Saboteur/Clone Warrior! BURN IN HELL NECROPHUCK!!!

ccovell

Quote from: TurboXray on 06/30/2016, 12:44 PMhuLala
HuVoila...
HuTain

Mon HuStie de Tabarnak

Je m'en Hu

HuKkake

(yeah, now I'm just getting hulgar...)

spenoza

HuBris (orthodox Jews might be confused by this)

HuVula

HuVox (serious suggestion, actually)

dshadoff

HuDunnit

HuStonWeHaveaProblem

HuOnlyLiveOnce

HuMor Me

touko

#74
Hutangclan

QuoteMon HuStie de Tabarnak
Do not mock of our quebecois cousins ​​ :P

dshadoff

HuYaGonnaCall - Ghostbusters

esteban

/HuFIN

(Close thread)
IMGIMG IMG  |  IMG  |  IMG IMG

TurboXray

#77

touko


TurboXray

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).

TurboXray

#80
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.

TurboXray

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.

Dicer

I'll give both packs a spin on real deal hardware tomorrow, looking forward to hearing it...

TurboXray

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:





      ;call                   ;8
     
      jmp [pointer]           ;7
     
active.part.one
      pha                     ;3
       
      phy                     ;3
      lda $0000               ;6
   
 
.RCR
      ;// RCR routine
      inc <IndexRCR               ;6
      bne .change.active.part     ;2
      st0 #RCR                    ;5
      sty $0002                   ;6
      lda <VDC_REG                ;4
      sta $0000                   ;6
                                  ; = 29
                                 
                                  ;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

Here's a version with a HDMA style system for doing Hint FX.





      ;call                   ;8
     
      jmp [pointer]           ;7
     
active.part.one
      pha                     ;3
     
      stz $402
      stz $403
      lda <BG0.l
      sta $404
      lda <BG0.h
      sta $405
 
      phy                     ;3
      lda $0000               ;6
   
      ldy <IndexRCR
      lda Dolist,y
      beq .skip
                        ;// X scroll
      bit #$01 
      beq .next1
      st0 #$07
      lda Xoffset,y
      sta $0002
           
.next1                  ;// Y scroll
      bit #$02
      beq .next2
      st0 #$08
      lda Yoffset,y
      sta $0002

.next2                  ;// Sprite off/on, BG off/on
      bit #$04
      beq .next3
      st0 #$05
      lda VDC_disp,y
      sta $0002

.next3                  ;// BG color #0
      bit #$08
      beq .skip
      lda BG0.lsb,y
      sta <BG0.l
      lda BG0.msb,y
      sta <BG0.h
     
.skip

.RCR
      ;// RCR routine
      inc <IndexRCR               ;6
      bne .change.active.part     ;2
      st0 #RCR                    ;5
      sty $0002                   ;6
      lda <VDC_REG                ;4
      sta $0000                   ;6
                                  ; = 29
                                 
                                  ;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.

Dicer

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.

:dance:

TurboXray

Find some decent 2 unlimited mods... then we talk.

 Someday, I want to do a PCE version of this demo:

Dicer

Quote from: TurboXray on 07/04/2016, 04:23 PMFind some decent 2 unlimited mods... then we talk.

 Someday, I want to do a PCE version of this demo:
Short megamix
http://janeway.exotica.org.uk/release.php?id=53397

Magic Friend
http://lite.modarchive.org/index.php?request=view_by_moduleid&query=121776

And because I've always like this one
http://janeway.exotica.org.uk/release.php?id=50127
BLUEBOXING

ccovell

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
lsr a
lsr a
lsr a ;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

TurboXray

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?

TurboXray

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:
.loop
.sm17   lda #$00                                  ;2
.cn6    adc #$00                                  ;2
        sta (.sm17 - TIMER_PLAYER)+BASE_SM1+1     ;5       
.sm18   lda #$00                                  ;2
.cn7    adc #$00                                  ;2
        sta (.sm18 - TIMER_PLAYER)+BASE_SM1+1     ;5           
        tya                                       ;2
.cn8    adc #00                                   ;2
        tay                                       ;2
.sm20   lda $0000                                 ;5
        bmi .chn3_chk                             ;2 
        sta bffr,x                                ;5
        dex                                       ;2
        bne .loop                                 ;4

 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).

      tst #nn, list,x ;8
      beq .skip       ;4/2
      iny
      iny
      iny
      iny             ;8
.skip
      lda abs,y       ;5
      sta bffr+x      ;5

8 of these in a row (self modifying code) followed by this:
      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...

ccovell

Quote from: TurboXray on 07/05/2016, 12:26 PMccovell: How did I not know about this demo!?
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:
IMG

Another test demo: https://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.

TurboXray

#91
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?

ccovell

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.

TurboXray

#93
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.

TurboXray

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.

TurboXray

#95
Quote from: ccovell on 07/04/2016, 07:26 PMIf 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
lsr a
lsr a
lsr a ;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
I just looked at this again, and noticed you're doing something a little different.
sax
and #$07 ;top 3 bits

If you set channel vol to $DF and second channel to $CB, you output 5bit values to both.
 As in:
tax
lsr a
lsr a
lsr a
sax
asl a
asl a

 Did you do an 8bit vs 10bit paired channel setup to save 2cycles per sample?

(edited)

ccovell

#96
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: lda #$02
sta $0800 ;Choose channel 2
lda #$99 ;#$99 gives 8-bit precision!
sta $0805 ;Panning
lda #$C0+$1F        ;DDA ON!
sta $0804 ;Write PCE Volume

TurboXray

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...

elmer

Quote from: ccovell on 07/11/2016, 08:13 PMI 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.
That's a nice bit of lateral thinking. Very cool trick to get 8-bit precision.  :D