libltc decoder returning zero

[zhiguang1]

I'm reading in realtime LTC from a timecode generator in through PortAudio in order to record it. Then I pass samples to the decoder:

//// data.decoder = ltc_decoder_create(data.apv, 1024); ////

in the callback function:

ltc_decoder_write_float(data->decoder, &data->recordedSamples[6][0], framesToCalc, data->frameIndex);

printf("queue %d",ltc_decoder_queue_length(data->decoder));

while (ltc_decoder_read(data->decoder, &data->frame)) {
    SMPTETimecode stime;

    ltc_frame_to_time(&stime, &data->frame.ltc, 1);

... etc etc

i've tried changing the window size, apv, queue size, etc, all returning zero. it seems that the maximum and minimum are being read, however.

[x42]

That looks correct. Also "returning zero" means no error, I guess you're not seeing any decoded Timecode values.

Is &data->recordedSamples[6][0] an array of non-interleaved floating point audio-data?

With portaudio's sample-format paFloat32 | paNonInterleaved and Pa_ReadStream() I'd expect a single array: &(input_buffer[channel * n_samples]).

Can you dump the incoming LTC to a file? That might be helpful to check if it's valid LTC or shed some more light on the issue.

[zhiguang1]

yes it is non-interleaved floating point audio, i'm parsing the channels out

how would I confirm that this is valid LTC?

[x42]

I'd first do a visual check in some sound-file editor. Expect 2KHz and 4KHz square waves (gapless) like

(there are 2 LTC sources overlaid in the image, and the timescale isn't visible, but it should give you a general idea)

If you have a short snippet (1-2 seconds should suffice) upload it and I can have a look.

[zhiguang1]

i have an audio snippet but can't upload here, unfortunately. here is a visual

[x42]

That looks fine. The LTC sync word is even visible in the data.

Is that a dump of &data->recordedSamples[6][0] loaded as raw data into audacity or did you record it with audacity?

[zhiguang1]

i recorded with reaper and opened with audacity actually...for a direct dump it would take some more effort

[x42]

or try vice versa: test the decoder with some raw data (dumped from the .wav, IIRC audacity can export raw audio data)

[zhiguang1]

i'm thinking now that this could be a floating point or float32 issue i.e. exponent/mantissa...will confirm shortly.

[zhiguang1]

no that wasn't the issue, i'm not sure if this is of any consequence or use, but it seems to read some data into some of the decoder vars

[zhiguang1]

so i used RAW audio data from audacity and it is giving such output:

[x42]

Well, that means LTC without date-information is detected. So it looks like a step forward and it indicates that the issue is indeed with interpreting the portaudio buffer as float array.

It's still odd that the same timecode is parsed over and over again. What compiler do you use and what's the target platform? Does make check pass the self-test?

The huge numbers at the end are the correspond to the index passed as last argument to ltc_decoder_write_float() for the given decoded LTC frame.

[zhiguang1]

i'm using the msvs compiler and targeting x86

[zhiguang1]

if I build in linux, make check passes the self test, but still same issue (decoding to zero) using a contiguous array