Jump to content

Photo

U-235 SoundEngine released!


77 replies to this topic

#51 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Tue Jun 4, 2013 2:00 AM

too bad, i thought it's a Tracker... :-(


If you want a Tracker, I'd suggest Open ModPlug Tracker, it's very full featured and supports all formats from the original MOD to XM etc. my sound engine is for playing back sounds and modules on the Atari Jaguar, not much point in having a tracker on the Jag itself (that I can see anyway).

#52 Der Luchs OFFLINE  

Der Luchs

    Dragonstomper

  • 501 posts
  • Location:Germany

Posted Tue Jun 4, 2013 2:12 AM

But how will I know, which Instruments and Freq are supported by the Jag?

#53 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Tue Jun 4, 2013 2:17 AM

But how will I know, which Instruments and Freq are supported by the Jag?


A tracker module contains the samples for the instruments. If you can create a valid Tracker or Pro-Tracker module, then the U-235 SE will play it (with a few outstanding effects still needing to be implemented, but those will come in time.)

For sample playback, as long as it is 8bit signed, most frequencies should be possible, not worth going much over 20kHz but you can if you want to use that much RAM

#54 Der Luchs OFFLINE  

Der Luchs

    Dragonstomper

  • 501 posts
  • Location:Germany

Posted Tue Jun 4, 2013 2:26 AM

What about .ASM or XEX export?

#55 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Tue Jun 4, 2013 2:35 AM

What about .ASM or XEX export?


Not at this time. Just Modtracker or ProTracker

#56 Der Luchs OFFLINE  

Der Luchs

    Dragonstomper

  • 501 posts
  • Location:Germany

Posted Tue Jun 4, 2013 2:53 AM

Ok, thanks!

#57 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Sat Jul 13, 2013 6:04 AM

Version 0.20 released (changelog), Fixed bug with looped samples making small sample loops sound horribly off-key, Vibrato & vol slide added, added a pseudo random number generator...

U235 SoundEngine Homepage

#58 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Mon Feb 17, 2014 6:41 PM

Version 0.21 released (changelog), Small update.  Now includes joypad reading feature.

U235 SoundEngine Homepage



#59 sh3-rg OFFLINE  

sh3-rg

    River Patroller

  • 2,029 posts
  • /|\
  • Location:NORTH-WEST ENGLAND

Posted Tue Feb 18, 2014 1:15 AM

NEW FEATURE: Joypad reading is now handled by the SoundEngine. Status of pad1 & pad2 can now be easily read via 2 longs

 

Looks like vlad could kill 2 birds (or a small flock) with one stone if he builds this into his basic.



#60 theloon OFFLINE  

theloon

    Quadrunner

  • 6,946 posts

Posted Tue Feb 18, 2014 1:20 AM

Yep.  I threatened to make Progress Quest if he didn't get real joypad support working.  I don't think he's ever forgiven me :)



#61 Otto1980 OFFLINE  

Otto1980

    Chopper Commander

  • 107 posts
  • Location:Poland

Posted Wed Mar 12, 2014 6:54 AM

hi linko
tryed a little you u235SE
very nice (also padreading/randnr)

just some questions:
dsp.obj is ~30kb
how much of it you load into dsp local ram?
plus 3 buffers? did i understand correctly?
(you know im just curious :D )

is this a .mod only tracker?
(didnt find that info in pdf :-D)

nice work..
cool to have !!
keep on this way

greetz

#62 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Wed Mar 12, 2014 7:09 AM

Glad you liked it :)

 

the object is 30KB because it has more than just pure code in there.  As well as the code there are all the linker labels etc, to allow it to be linked into other peoples code.  It also includes the 68K to setup the Mod player (sets up sample banks, tempo, etc) and a lookup table or two.  The DSP code is probably around 3-4K, and the rest of it is variables and sound buffers.  Once a mod is setup it runs 100% on the DSP, you can test this by starting a mod and then issuing an 'illegal' or 'stop' to the 68K, it will keep playing :D

 

It would be possible to write a parser for another mod format in 68K land and pass the playback instructions to the SE if you wanted to play something other than a SoundTracker/ProTracker mod.  Internally this is how it works, the parser parses the mod and just creates playlists to pass to the SE internally making it nice a modular :D

 

I bundled it all into the one object to keep things neat and tidy, just need a few files in your own project workspace to make use of it.

 

You are right it does also have some buffers in the DSP RAM, there are 2 which feed the DACs, and each voice has it's own very small cache buffer.

 

It is primarily a Sound Engine that just plays samples, A pad reader and RNG.  I have also bolted onto it a Module parser so it can parse SoundTracker/ProTracker modules.  The big picture would be that this can be switched out for other formats (Octamed etc), or possibly other sound sources (I have got some very rough CD Audio playback code kicking about, and also dabbled a bit with pure synthesis of sounds).  There are still plenty of tweaks to be made to the existing codebase, and I think I can possibly improve the performance of the SE itself further and reduce its impact on the system bus hopefully.



#63 Otto1980 OFFLINE  

Otto1980

    Chopper Commander

  • 107 posts
  • Location:Poland

Posted Wed Mar 12, 2014 7:34 AM

very cool... sound you on the best way to create the standard jaguar sound library ;-)

 

is this buffering dynamic? or more static?

 

example

 

mod size: 20 kb

2 x buffer size: 2 kb each, so 4 total

 

so you have 10 "buffer loads"

 

are they static?

i mean:

buffer 1 gets kb 0 to kb 2 of the mod

buffer 2 gets kb 2 to kb 4 etc, etc,...

 

some theory just for my curiosity?

 

;-)



#64 theloon OFFLINE  

theloon

    Quadrunner

  • 6,946 posts

Posted Wed Mar 12, 2014 7:36 AM

Anyone caught using anything but mod music on the Jag should be strapped to an R-Zone and force fed items from Poundland.



#65 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Wed Mar 12, 2014 7:46 AM

The buffers are static, they are only about 512bytes each IIRC (would need to go rummaging in code to confirm :) ), all they are used for is precalculating the output to feed to the DAC, once the buffer has been played it is re-computed whilst the 2nd buffer is played, and vice versa.

 

The cache is only 4bytes per voice, although I am looking to change how most of this works.

 

Unfortunately for a single pattern within a mod you need 1K of RAM, I did consider caching the pattern data, but given the low frequency that it is read and size of it made that pointless.  I am also working on some alternative approaches to reduce the memory footprint of the module format, possibly leading to better caching and playback performance too.

 

 

Anyone caught using anything but mod music on the Jag should be strapped to an R-Zone and force fed items from Poundland.

 

Actually, I disagree :D  I have always thought the Jag should be playing stuff that sounds much better than 4channel mods, after all the Amiga (*SPIT*) used 4 channel mods all the time, the Jag is so much more than an Amiga (*SPIT*) so I would like to hear it do more!  (Yep I have my own ideas and plans around this :D )



#66 Otto1980 OFFLINE  

Otto1980

    Chopper Commander

  • 107 posts
  • Location:Poland

Posted Wed Mar 12, 2014 7:52 AM

ever thought about some kind of compression?



#67 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Wed Mar 12, 2014 8:04 AM

Problem with compression is you have to uncompress it to use it, and you have to uncompress it somewhere.  I may look into ADPCM, but that is only going to reduce the size of the source data and bus utilisation (potentially depending on LUT size) not the processed data.  There are significant savings to be had by reorganizing of data structures as well as reduction in bus bandwidth and CPU utilisation



#68 theloon OFFLINE  

theloon

    Quadrunner

  • 6,946 posts

Posted Wed Mar 12, 2014 8:51 AM

Actually, I disagree :D  I have always thought the Jag should be playing stuff that sounds much better than 4channel mods, after all the Amiga (*SPIT*) used 4 channel mods all the time, the Jag is so much more than an Amiga (*SPIT*) so I would like to hear it do more!  (Yep I have my own ideas and plans around this :D )

 

Oops.  My lack of 68k computing experience is showing.  I was running mods like this on my PC back in the day:



#69 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Wed Mar 12, 2014 8:55 AM

I'd certainly like to see what nice noises a Jag could produce with the involvement of a talented musician and some experimentation with synthesis stuff.  If the synth sounds can be done entirely in the DSP then the impact to the bus could be very low, and we could have some nice 16bit Stereo audio coming out of our speakers.  Not sure if the DSP can match the audio quality of an Ultrasound or anything with a Wave table, but it should be possible to make some really nice sounds.



#70 Otto1980 OFFLINE  

Otto1980

    Chopper Commander

  • 107 posts
  • Location:Poland

Posted Wed Mar 12, 2014 10:30 AM

yes i understand the compression problematic

now you maybe understand my previous questions :-D

the dsp speed itselfe would be enough for a simple decompress.. its just about the 8k and the task managing inside..

i am right?

8k of dsp ram and what is possible inside :D :D :D

 

because... as you say ... compressed data is smaller... also smaller to transfer via bus.. also smaller bus-use by the dsp

thats why i asked for the buffers and size and also dynamic or not

 

just an idea or vision.. didnt think very deep into the topic yet

 

greetings


Edited by Otto1980, Wed Mar 12, 2014 10:32 AM.


#71 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Wed Mar 12, 2014 10:53 AM

Yeah runtime decomp could possibly work, but this isn't really going to work for a file structure like a mod.  Inside a mod file there are several tables of data.  Sample data table, song data, pattern data and the samples themselves.  When you play a mod you look in the song data to find what pattern to play, then in the pattern table you need to read each division of that pattern at the appropriate time.  So the problem becomes, what do you compress?  If you compress pattern data, you are possibly going to need to compress it into small chunks and then decompress those chunks when you read them in to be able to use the data.  The smaller the chunk size the easier it will be and less buffer it will need in the DSP, but also the less compression benefits from that compression (depending on compression algorithm will depend on additional overheads of the process too).  So compressing the song/pattern data may be too problematic to be of much use (a typical mod with a playspeed of 6 will only read 16 bytes from main RAM once every 0.12 of a second, so not a big hit)

 

Data like samples which are pulled from the bus constantly typically don't compress very well due to their structure, you would need to read in (most likely) more data to be able to decompress the data you need to mix the samples together.

 

And as you have mentioned, only 8K of RAM for use as buffer space.

 

There may be techniques out there I am not aware of that could benefit things (I don't claim to know everything :D ), I am certainly not aware of any, and don't think for the work required there would be significant benefit.  I am more interested in pre-caching as much of a sample as possible into the DSP RAM, then feeding the SE from these caches, the SE already does this but only for 4x8bit samples per sample, which doesn't sound much but it's effectively reducing the number of bus reads for a sample by half.  (DSP has a 16bit bus, each read fetching 2 8bit samples, twice, possibly some benefit from 1x 32bit read rather than 2x 16bit reads etc).



#72 Otto1980 OFFLINE  

Otto1980

    Chopper Commander

  • 107 posts
  • Location:Poland

Posted Wed Mar 12, 2014 11:15 AM

yes.. i see we understand each other..

.mod module is already really small and the facts its a tracker (uses tracks) is already a kind of compression (only in view of size, not tech ;-)

splitting a .mod into 2k pices and compress them, compile them into the binary to have memory benefit.. i think to much work for small gain.

 

maybe now you understand my question about the buffers

because for decompression you must know how huge a datapart is and how decompression algorythm works

e.g. can you read kb for kb and decompress with the algorythm or does the algorythm require the whole datasection for his math.

 

we do not even have 8kb for buffer.. cause a SoundEngine also needs his space, right?

 

greets



#73 LinkoVitch ONLINE  

LinkoVitch

    River Patroller

  • Topic Starter
  • 2,267 posts
  • Location:Manchester UK

Posted Wed Mar 12, 2014 11:59 AM

Well, not really :).. If you load up a mod in an editor and look at the pattern data, one thing I have noticed is there is often a lot of empty space and repetitions.  So quite a lot of the time there is wasted effort reading in instructions that are essentially the musical equivalent of a nop.  If we were to remove all those holes we can save a huge (relitively speaking) amount of space, get rid of the duplicate data and save even more.  And that's without compression!

 

If you were going to look at compressing it I would imagine you would decide on a chunk size to break the data into, say 64bytes ;) of data, then compress that.  This way at least you will know that the uncompressed data will always be no more than 64bytes.  My (basic) understanding of compression is around the Huffman approach and as such a kind of dictionary will be required, I suppose to remove the need to require one for each 64byte chunk you would produce one for the whole dataset, or at least a larger window to gain as much of an optimisation as possible.

 

there may be some merrit to compressing the pattern data, however I doubt it will be significant, or give a significant gain to performance.  I will bear it in mind and if the mood takes me, I may look into it further.  There are however bigger gains to be had from much less work first :D

 

Indeed, the 8KB already holds the actual SoundEngine code, it's variables, as well as some small buffers.  It may be possible to allocate some of that for pattern data, but as I said earlier the amount of time spent reading pattern data is very minimal, and given the improvements I already have planned this would be reduced further anyway.  Restructuring the mod data, working out a compression scheme and then the code needed to work with that is perhaps an interesting challenge but ultimately for small gains.



#74 ggn ONLINE  

ggn

    Dragonstomper

  • 659 posts
  • Location:Athens, Greece

Posted Wed Mar 12, 2014 3:35 PM

If you want to toy around with compressed sound, grab the source code of Tripper and take a look. And then send a patch to Linko for his SE - as we all know patches are always welcome :D.

(especially patches for closed sourced code :P)

#75 Chilly Willy OFFLINE  

Chilly Willy

    Moonsweeper

  • 477 posts
  • Location:The Land of Enchantment

Posted Wed Mar 12, 2014 7:45 PM

The venerable MOD format can handle more than 4 tracks - I've seen up to 32 tracks. My own MOD player code for the 32X and SCD handles up to 8 tracks, but it's super-easy to add any number of tracks. There's also XM (extended mod) format, which handles up to 32 tracks by default. I made a player for the 32X that works great, so playing XM on the Jaguar should be doable as well. MOD and/or XM should be sufficient for most Jaguar games. When you need a really odd piece of music or sound effects, ADPCM like Tripper plays should be fine.






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users