SC88 should work without much headache when you can get the data format accepted by the transmitter chip but SC55 are impossible as they don't meet any criteria for the SPDIF or modern DAC chips to work. They have *average* sample rate (one sample lasts more clocks than next) and they don't have exactly 24/32/48/64 clocks per sample but some very strange amount (I no longer remember the details).

Tiido wrote on 2021-05-15, 10:04:

SC88 should work without much headache when you can get the data format accepted by the transmitter chip but SC55 are impossible as they don't meet any criteria for the SPDIF or modern DAC chips to work. They have *average* sample rate (one sample lasts more clocks than next) and they don't have exactly 24/32/48/64 clocks per sample but some very strange amount (I no longer remember the details).

Thank you for clarifying that . I naively assumed that the SC-55 would be using using an I2S DAC, considering how old that standard is, but I guess Roland decided to do their own thing . I will post my results when I receive the parts I ordered and get around to testing .

Another option that I had been considering, for the SC-88VL, was to use a sound card with I2S input, like the Audigy 2 ZS (which I do not have ) or an X-FI (whose I2S input apparently is only enabled when a front panel/drive is connected) . It is unclear to me whether 32KHz input would be supported by one of those anyway . If it did work on an X-FI (probably would requiring modding the card or a front panel/drive, or adding an interposer to bypass I2S signal coming from the front panel/drive), it might actually be worthwhile just to take advantage of the X-FI's rather well regarding sample rate conversion .

I2S is "vague", it usually consists of bit clock, LR clock and sound data signal, and non oversampling DACs accept any timings and whatnot, but all modern parts require rigid timings (x amount of clocks per sample) and also a master clock that has a special relationship with other signals. Sample rate itself is not a limiting factor for transmission, only receival, depending on if the receiver can sync to incoming clock on it tries to force data out using its own local clock (which will be subject to variety of artifacts).

SC55, GUS and many other old devices use all sort of funky timings etc., only later stuff has output that is something a modern part will properly understand and can utilize. SC88, most Yamaha devices etc. have all necessary for usage of modern parts.

Tiido wrote on 2021-05-15, 19:40:

I2S is "vague", it usually consists of bit clock, LR clock and sound data signal, and non oversampling DACs accept any timings and whatnot, but all modern parts require rigid timings (x amount of clocks per sample) and also a master clock that has a special relationship with other signals. Sample rate itself is not a limiting factor for transmission, only receival, depending on if the receiver can sync to incoming clock on it tries to force data out using its own local clock (which will be subject to variety of artifacts).

SC55, GUS and many other old devices use all sort of funky timings etc., only later stuff has output that is something a modern part will properly understand and can utilize. SC88, most Yamaha devices etc. have all necessary for usage of modern parts.

Thanks again . I also just realized that the SC-88VL is likely 5V but the WM8805 is 3.3V on the I/O side (AFAICT from the datasheet), so I ordered some level shifters as well .

While I patiently wait for transceivers to arrive, I have been giving some thought to what equipment I might have or need to buy that is actually capable of accepting a 32KHz S/PDIF signal .

- SB1040 ? ALSA won't allow setting a 32KHz capture rate
- CM6206 ? ALSA won't allow setting a 32KHz capture rate even though, ironically, https://github.com/vestom/cm6206ctl shows that the chip actual sees a 32KHz signal coming in (and chip supports 32KHz S/PDIF input according to datasheet).
- Custom SA9226 device ? Chip supports 32KHz S/PDIF , but Windows won't allow setting input to 32KHz (have not tried ALSA yet, but not getting hopes up)
- ADS Instant Music based on TI PCM2902 ? That one actually accepts 32KHz and ALSA agrees . Yay! The catch ? If S/PDIF signal is not detected, defaults to relatively noisy ADC input (AFAICT, no way to disable this behaviour). Kludgeable in a pinch, but not ideal .
- M-Audio Delta66 ? Have not tested it yet under Linux, but seems to support 32KHz S/PDIF input . However, the only card that I have is actually in use, so would either need to replace or buy another one .

If anybody has any suggestions for something that is cheap, obtainable, has 32 KHz S/PDIF input, does not resample, is preferably USB and is either class compliant or has a working device-specific ALSA driver, I would love to hear them .

EDIT : Found a cheap TerraTec EWS88 MT PCI without the breakout box . This or the Delta66 should work nicely under Linux , hopefully including at 32KHz .

Well, sucks to be me . I soldered a wire to a chip pin to tap 5v and was able to solder one of my 4-channel level shifters . After that I managed to lift the pad at point C32 and cut the trace that leads to the DAC . I am pretty sure I have found some vias where the signal is present but, at this point, I don't trust myself to solder a bodge wire. I am even more unlikely to try soldering to the corresponding pin on IC36 (where the signal originates), considering the tight pitch pitch and my sucky soldering skills .

I guess will have to see about having it repaired with a bodge wire and maybe have wires soldered to the proper points to tap the I2S signals .

I have a place close to me that may be able/willing to do that . The cost may, however, be more than it is worth . If that is the case, I would like to gift it (for the price of shipping) to somebody here with the skills to repair, if that is acceptable under current application of forum rules .

In the meantime, I will practice my soldering skills (or lack thereof) on cheap/dead hardware before I attempt anything like this again .

That is unfortunate...
The fix should be easy though and it will help to use thinnest possible wires to prevent things like this from happening (I have been using wires found in 80 conductor IDE cables but there are thinner things out there too that would be even better to use). If all else fails I can certainly bring it back to life. Do you have photos of the problem area ?

Tiido wrote on 2021-05-29, 04:48:

That is unfortunate...
The fix should be easy though and it will help to use thinnest possible wires to prevent things like this from happening (I have been using wires found in 80 conductor IDE cables but there are thinner things out there too that would be even better to use). If all else fails I can certainly bring it back to life. Do you have photos of the problem area ?

Thank you for your help and encouragement .

I will take a photo tomorrow and post it . It is way past my bedtime at this point .

Sorry if I have not posted pictures of damage yet. I have been able to run a bodge wire between a via and the BCLK pin on the DAC chip, which restored analogue audio. I soldered the wire to the proper pin on the DAC and, shamefully, as I did not see myself as being able to solder to the via, I just wedge the wire into the hole and, wait for it, hotglued ! I works for now and the fix cost me 0 dollars, so that's something. My soldering skills and confidence will eventually improve and I will likely be able to fix it properly later on .

Once I saw that this worked, I tapped the SDATA and LRCK the same way (wire in the via with a blob of hot glue on top and wired everting into 3channels of my 4 channel level shifter (I also connected ground and reference voltage on both HV and LV side )and then into the I2S to S/PDIF transceiver . Unfortunately, I get no sound whatsoever using the ADSTech Instant Music S/PDIF input set to 32KHz under Windows . I also tried bypassing the level shifter temporarily and get the same result .

The S/PDIF receiver toslink emitter turns stable on when BCLK is connected (otherwise it flashes), but that's about all the good news . I will post photos of the I2S S/PDIF transceiver, the damage and my shameful hot glue blobs when I get the chance . I might read up on how the WM8805 and the Toshiba chip in the original project (link in Japanese) differ to maybe find an answer, or I will just take a chance on an Aliexpress/Ebay sourced NOS/refurbished (who knows) chip and copy the layout/design of the original project to a T .

At least it works again ~

I have used DIT4096/4192 successfully. But there's need to do format coversion since nothing supports the 18bit output and that's what the extra parts are doing on the links. Direct connections should still work, just without proper fromat conversion you'll have garbage sound but whatever you are feeding the signal to should see it and sync to it, assuming there's 32KHz support on it.

Tiido wrote on 2021-05-31, 09:23:

At least it works again ~

I have used DIT4096/4192 successfully. But there's need to do format coversion since nothing supports the 18bit output and that's what the extra parts are doing on the links. Direct connections should still work, just without proper fromat conversion you'll have garbage sound but whatever you are feeding the signal to should see it and sync to it, assuming there's 32KHz support on it.

If the SC-88VL is actually generating 18-bit data internally, I naively assumed that the least significant bits would get truncated (not ideal, I know) but would otherwise work .

I retried with a less primitive audio card, an M-Audio Delta66 (under both Windows XP and Windows 10), which I am pretty certainshould handle 32 KHz input over S/PDIF (I set options according to the example on page 37 of the manual, but specified 32KHz) and I am not even getting an S/PDIF lock-on . I know my Delta 66 S/PDIF input des work because I recently used it, albeit with with a 44.1KHz source .

So the transceiver apparently does not even like the BCLK it is getting (unless I am doing something obviously wrong, or the transceiver is dead or damaged), or maybe the WM8805 requires more than just a BCLK signal to actually want to generate valid S/PDIF output ? If I had a multi-channel oscilloscope, I could answer that . Maybe it's trying to run in master mode, rather than the slave mode I believe it should be defaulting to ?

In case it is not completely obvious already, I am a newb at this and I have no idea if I am making any sense .

I am close to giving up on trying to understand what I am doing and simply building a conversion circuit exactly as described in the link in Japanese and hoping for the best. My only worry is sourcing a non counterfeit version of that Toshiba transceiver chip .

The problem is the way data is output, Japanese love to use right justified formats, where you must capture all the bits or you are missing the MSBs and nothing supports formats other than RJ16 pretty much. Only with Philips I2S or Left Justified format do the LSBs get dropped, so you can support arbitrary bit depths for single setting. For whatever reason, Japanese thought right justified is better, despite the fact it requires a new format selection for every bit depth...

Master mode would destory hardware, if that is the case you will have to make sure the chip is 100% configured right. Scope would definitely help but at this point you will definitely need to go for exact parts as seen on the japanese site, those are guaranteed to work. I used a CPLD to covert the format to I2S so that I can use any modern parts, though not with VL but SC88pro equivalent hardware. I am not sure they are completely similar since the data format is firmware configurable.

Tiido wrote on 2021-06-01, 07:50:

The problem is the way data is output, Japanese love to use right justified formats, where you must capture all the bits or you are missing the MSBs and nothing supports formats other than RJ16 pretty much. Only with Philips I2S or Left Justified format do the LSBs get dropped, so you can support arbitrary bit depths for single setting. For whatever reason, Japanese thought right justified is better, despite the fact it requires a new format selection for every bit depth...

Master mode would destory hardware, if that is the case you will have to make sure the chip is 100% configured right. Scope would definitely help but at this point you will definitely need to go for exact parts as seen on the japanese site, those are guaranteed to work. I used a CPLD to covert the format to I2S so that I can use any modern parts, though not with VL but SC88pro equivalent hardware. I am not sure they are completely similar since the data format is firmware configurable.

Thank you for all the information. I had not even considered justification or even endianness or inter signal-phase requirements (or whatever else clueless me is forgetting or ignorant about, 🤣) for that matter . I now understand that I2S is more of a set of guidelines than anything that is actually formally standardized (correct me if I am wrong).

So my options are :
a) live with analogue output (going digital was more of a whim than anything else), and, AFAIK, the same DAC was used in the pro-grade JV-1080 (possibly with a better analogue stage, though).
b) become good/knowledgeable enough (and get a scope) to actually design and build a proper conversion circuit using current parts (nothing is impossible, but I don't see this being likely any time soon).
c) Build the conversion circuit as closely as possible to what is described in that link in Japanese

At the end of the day, option a) is likely the most sane approach .

Thank you again for helping educate me .

I2S has come to mean the LRCLK+BCLK+SDATA combination, but yes, there are different formats available on those signals that are not what the link originally was meant to carry. Philips format (the real I2S), Left Justified (almost same as Philips but lacks a dead cycle before MSB) and Right Justified (Japanese) formats with 16bits being most common and 18 bits less common but 20 bit exists too.

Analog output of the device should be more than adequate. There's also some extra aspects about it such as intentional low freq boost that will be missing on digital output.