VOGONS


First post, by darksheer

User metadata
Rank Member
Rank
Member

Would it be possible to adapt some AWE32's S/PDIF like interface to a GUS Max ?
If I am not mistaking the digital signal coming from the GF1 chip should arrive to the TDA1545A DAC (through its DATA/WS/BCK PINS ?).
If that's really the case could it be possible to wire or to convert that signal to a S/PDIF interface ?
Thanks 😀

Reply 1 of 5, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

Should be possible. The DAC format looks pretty standard that should work with most SPDIF transmitters that are configurable. It is not I2S audio bus that would be the most compatible.

I have some GUSes packed away in a box, I could take a look at some point if I find them.

Reply 2 of 5, by darksheer

User metadata
Rank Member
Rank
Member

Thanks for your interest 😀
After some research it appears that the singal fed through DATA/WS/BCK to the TDA1545A DAC should be at the EIAJ 16-Bits norm and so it could be send to a TOSLINK interface (or wired to a red LED).
Now I wonder if it would be as simple as (yeah that would be too easy 🤣) to wire these buses toghether to build the EIAJ signal and then feed it to a red LED or else if the use of some TTL's, caps and resistors are necessary...

Reply 3 of 5, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

No, you really need a special chip called serial audio transmitter. It is a chip that takes in the 16-bit PCM data from the serial audio bus (WS, BCK, DATA) and encodes the data into SPDIF format. You can then connect the SPDIF output to TOSLINK optical transmitter module or RCA connector. For example look at this chip : http://www.cirrus.com/en/products/cs8406.html.

The downside is that the SPDIF chip usually needs a master clock signal (it's the clock that gets divided down to generate the BCK and WS clocks). That may or may not be available on GUS, needs some investigation. Some SPDIF transmitters may work without it, as they may be able to regenerate this inside them from BCK and WS clocks. Or with another chip that can generate it.

Also there is one problem, the GUS sampling rate depends on how many channels you want to output. At 14 channels, it's the standard 44.1 kHz that any home A/V equipment will happily accept over SPDIF. At 32 channels, it's non-standard 19 kHz and I bet very few A/V equipment, if any, will play it. (IIRC, the formula for the sampling rate is Fout=44100*14/channelcount, where channelcount cannot go below 14 and above 32).

But still, it would be an interesting project.

Reply 4 of 5, by darksheer

User metadata
Rank Member
Rank
Member

Very interesting infos, yeah I also thought about the variable sampling rate but for MIDI music playback only I don't really think that more than 14 channels are usually used or needed, but if it's the case it's indeed problemtaic.
The funny thing is there will be any differences from recording an emulated GUS output and recording from a real GUS S/PDIF interface considering that the instrument patches and the basic way they are used is the same ? 🤣

Reply 5 of 5, by Jepael

User metadata
Rank Oldbie
Rank
Oldbie

I'd say it depends how good the emulator is of course 😀
Most likely the emulator takes few shortcuts here and there to save CPU horsepower to emulate the rest of the system, so it may not implement all the details.
The way how GUS interpolates samples sounds really awesome (at least it did in 1994 or so when playing tracker music), but I don't think emulators use the same interpolation method.

The sampling rate is a problem if you want to play it in real time over SPDIF. If you have the equipment to capture the data on the audio bus to a WAV file first, then you always have the original data and you can play it on your PC after sample rate conversion.