Rockbox

the patch.

   tap_codec.diff (12.9 KiB)

You can't use floating point arithmetic on Rockbox, I'm afraid; almost none of our targets have hardware floating point. You'll need to do this using integers/fixedpoint…

Looking at the create_pulse function, I think its only called with constant arguments during the initialization. Perhaps you could eliminate all that floating point code just by precomputing the values in buffer[]?

@saratoga : Sure, this was my first thought but I found it more flexible creating the buffers with code. It was easier to experiment with pulse width/amplitude that way. And I don't think it is a big overhead even for software floating point support. @torne : Does the targets support software floating point?

Software floating point apparently more or less works (though with restrictions) but it's *hundreds of times slower*. If it's just generating a table then including the data in the binary would be easier and reduce codec startup time probably significantly (and might actually produce *smaller* code; the table may well be less bytes than the floating point support code that gcc will generate for you)

Do you mind if I add a #define statement that switches the compilation between floating point / precalculated buffers? It is quite handy during development and I could use the code to produce the actual buffer[] contents.

If you add a #define to switch between pre-calculated tables and the float calculations this should be fine. Can you please also provide an update of the manual (see ./manual/appendix/file_formats.tex) which introduces the new format and its supported metadata, as well as a sample file?

Edit: You should also insert AFMT_TAP after AFMT_KSS to avoid breaking older skins which depend on the codec order.

I have added the manual changes and changed the location of tap-related definitions.

Edit: Btw, I downloaded 2 samples (see the attached files) and the result does not sound as intended. Can you please check?

   tap_codec_v02.patch (15.2 KiB)
   TRANSAM.TAP (15.5 KiB)
   WINTER1.TAP (48.1 KiB)

The attached tap file should be appropriate and usable

   rockbox.tap (6.9 KiB)

a flac file of the above for reference

   rockbox.flac (1.25 MiB)

Do you actually need sine waves at all? The "tapeout" program that comes with spectemu uses square waves

I'm afk for the moment, I'll check all comments as soon as possible when I get back.

@Buschel : Doesn't matter how they sound as long as spectrum loads them. My spectrum loaded easily on the first try Transam.tap and rockbox.tap. It cannot load winter1.tap, as it only has 16k of RAM.

@fg : I tried them all. Square, trapezoid, triangle and sine waves. Sine waves works best, trapezoid comes second then triangle and final square waves. Spectrum bit detection is triggered on the pulse edge, not level. My guess is that if the edge is very "steep" or very "flat", it might miss it. Square waves never worked for sansa clip+, it worked only with the simulator and only at 100% volume.

I created a new patch. Now floating point calculations are optional. When enabled, the codec prints out the precalculated tables code that can be copied directly into the source.

   tap_codec_v03.patch (17.5 KiB)

Ah, that makes sense. I remember that a few years ago not all of my players were loud enough to work for this, and I used tapeout back then…

Another think is that bass and treble should be set by the user at level 0, otherwise the signal is distorted and spectrum cannot recognize it. Is there any way to do it in my codec initialization and revert it to original settings on codec cleanup ?

   tap_codec_v03.patch (17.5 KiB)

Oops, please ignore the second tap_codec_v03.patch. I double posted it by mistake.

May i ask: why somebody would really need to listen to tape loading sound from ZX spectrum? :P Well… as a joke, huh?

Listen? No. Use it to feed a .tap file into an actual ZX spectrum? Yes.