Bug 1692 - 8 channels, 32 bit TDM output hard to read, not configurable for different frame options
Summary: 8 channels, 32 bit TDM output hard to read, not configurable for different fr...
Status: CONFIRMED
Alias: None
Product: libsigrokdecode
Classification: Unclassified
Component: PD: tdm_audio (show other bugs)
Version: unreleased development snapshot
Hardware: All All
: Normal normal
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-06-21 17:47 CEST by robca
Modified: 2021-06-25 23:52 CEST (History)
0 users



Attachments
Screenshot+signal capture files (52.79 KB, application/zip)
2021-06-21 17:47 CEST, robca
Details
proposed fixes to tdm_audio decoder (4.30 KB, text/plain)
2021-06-25 23:50 CEST, robca
Details
Decoded signal before fixes (120.33 KB, image/png)
2021-06-25 23:52 CEST, robca
Details
Decoded signal after fixes (96.37 KB, image/png)
2021-06-25 23:52 CEST, robca
Details

Note You need to log in before you can comment on or make changes to this bug.
Description robca 2021-06-21 17:47:56 CEST
Created attachment 734 [details]
Screenshot+signal capture files

I'm using a DsLogic analyzer and PulseView to look at the output from an ADAU1452 DSP. The DSP is programmed to output 8 channels, 32 bit on the 3 TDM signal lines. I'm including a screenshot from Pulseview and the signal capture files. In this example, the first 6 channels (Ch1-6) are muted and there is an audio signal only on the last 2 channels (Ch7 and Ch8)

There are 2 problems with the current decoder. Actually one is a problem, the other a missing feature (made worse by the first problem):
*) the current decoder uses a confusing mix of channel numbers. What is decoded as Channel 8 is actually shown on the TDM Audio: Ch0 line. It looks as if the decoder is confused about using an Index0 vs Index1 convention. Most technical documentation for TDM seems to use the Ch1-ChN convention. So displaying Channel 1-8 makes sense, but it's confusing to see Channel 8 at the top of the display in the Pulseview window (see screenshot)
*) my signal uses a falling edge on the "frame" input as start of Ch1. The current decoder always assumes that Ch1 is marked by a rising edge, so the display is shifted by 4 channels (i.e what is channel 7 and 8 for me, is decoded as Ch3 and Ch4). In the decoder there is an option to use rising or falling edges, but that is only for the data portion. It would be very helpful to be able to also define the option of a "positive" and "negative" frame, so that Ch1 is really Ch1 and not Ch5

Please let me know if you prefer to have this bug split into a bug and a feature request
Comment 1 robca 2021-06-25 23:50:21 CEST
Created attachment 736 [details]
proposed fixes to tdm_audio decoder
Comment 2 robca 2021-06-25 23:50:36 CEST
I started looking into the decoder APIs and I realized that, even with my non-existent Python knowledge, it was possible to address the issues I saw.

I'm including a new version of the tdm_audio decoder that shows the channels in the correct order (1-8) and adds a protocol option for positive or negative frames (called "Frame polarity", default value is the same as before, positive, and negative for signals like mine)

I tested it only for 32 bit frames, 8 channels. Within that limit, the new decoder behaves like the old one in terms of values. I do not have access to different tdm streams at the moment. If I can find more, I'll add to this issue.
Comment 3 robca 2021-06-25 23:52:09 CEST
Created attachment 737 [details]
Decoded signal before fixes

Adding before/after screenshots from Pulseview, using the same sr file attached to this bug
Comment 4 robca 2021-06-25 23:52:34 CEST
Created attachment 738 [details]
Decoded signal after fixes