<zmatt>
part of the output of my asp-monitor is the state of the I/O lines, which I suggest verifying without the ad7771 connected just as a sanity check. Hopefully you're not color-blind since the important thing to check is only indicated through color: https://pastebin.com/raw/q5vGftvA
<Siegurd1>
It works!
<Siegurd1>
I entered arecord -c 8 -r 128 -f S32 and data starts to flow. In parallel terminal asp-monitor shows data transfering with arrows. When I shout down AD7771 data flow stops
<zmatt>
nice
<Siegurd1>
I'm so excited!)
wonko-the-sane has joined #beagle
<zmatt>
you'll obviously want to double-check whether the channel order actually matches what you're expecting and such
<Siegurd1>
shure
<zmatt>
but the AD7771 sticks an 8-bit header into each sample that includes the channel number, so you can use that to confirm
<Siegurd1>
AD7771 gives channel number and CRC in each frame
<Siegurd1>
so now I can record this into a *.bin file and read with hex editor?
<zmatt>
for example yeah, if you record it into raw format (I think by default arecord will use WAV format)
<zmatt>
oh btw be sure to use the raw hw: device, you don't want any kind of conversion layer inserted by alsa
<zmatt>
I think it's -D hw:
<zmatt>
I think it shouldn't insert a conversion layer anyway as long as you specify values that the hw device supports (and in this case the hw device supports pretty much anything, or at least it will erroneously pretend that it does) but still, better to be sure
<Siegurd1>
ok, I'm just wondering, where is the 8 MHz CLK frequency setuped?
<zmatt>
?
<zmatt>
are you referring to the 8192 kHz oscillator that's on your AD7771 eval board/
<Siegurd1>
Yes
<zmatt>
since that's just a fixed osc
<zmatt>
so there's nothing to setup afaik
<Siegurd1>
but how driver know that it should be working at this frequency? Or its just interrupt driven?
<zmatt>
the driver doesn't know or care about the 8192 kHz clock, it doesn't interact with it in any way
<Siegurd1>
hmmm
<zmatt>
oh wait you mean the bit clock, which is also 8192 kHz
<Siegurd1>
yes
<zmatt>
well my DT overlay in combination with the settings you provide from userspace tells the driver what format and rate to expect... though in the end the rate isn't super important anyway since mcasp is the clock slave
<zmatt>
like, if the clock had a different rate then it would just be receiving data at a different rate
<zmatt>
perhaps in that case something might complain that data seems to be arriving at the wrong rate but I'm not even sure about that
<Siegurd1>
i gues its interrupt driven cuz I have not setuped any frequency on SPI slave. Only on master.
<zmatt>
I don't know what you mean by any of that
<Siegurd1>
in STM32 projects
<zmatt>
the kernel driver will setup dma to get the data automatically transferred by hardware to buffers in memory, and for each block (you can configure the block size from userspace) the driver will get an interrupt which causes userspace to be notified that a new audio block is available
<zmatt>
the AD7771 is driving the data clock so it is ultimately in control over how fast data is being transferred
<Siegurd1>
What I mean is that any SPI slave device does not need to be tuned. Usually, only the maximum frequency of the CLK line is indicated in the datasheets. Therefore, the frequency is configured only on the side of the master. And the slave works on interrupts.
<Siegurd1>
You are right!
<zmatt>
SPI is just a very different story overall, since the SPI interface is command-oriented and its clock rate is not directly dependent on the sample rate, it just needs to be fast enough
<zmatt>
while mcasp is expecting exactly 2*32 bits of data (per line) for each sample period, so the bit clock frequency is exactly 64 times the sample rate
<zmatt>
I did see in the AD7771 datasheet that it is capable of using a sample rate lower than that (i.e. have idle clock cycles between frames) but I don't know if mcasp tolerates that
<zmatt>
I'm pretty sure it doesn't
<zmatt>
yeah I don't know why I said I don't know whether it tolerates that, I actually do know that: it doesn't tolerate it, it would signal a framing error.
<zmatt>
but that's only an issue if you wanted to use its sample rate conversion feature to run the adc at weird or variable rates
<zmatt>
(that would probably require using PRU to receive the data instead)
<zmatt>
huh, that string doesn't even occur in my current source code
<zmatt>
this must be some old version
<Siegurd1>
maybe I should enter 64bit and 4 chanels instead of 8/32?
<zmatt>
no
<Siegurd1>
when I do -r 192 the are no warnings. Strange
<zmatt>
redownload asp-monitor, I've replaced it with a newer build
<Siegurd1>
ok
<zmatt>
note that it will give wrong info about clock frequencies since it doesn't actually have any idea what the actual clock rates are (it just assumes an 48 kHz sample rate), but it's the frame format info I'm interested in
<zmatt>
ok 2 slots/frame * 32 bits/slot is correct
<zmatt>
I'd suggest double-checking the configuration of the AD7771 ... or check the actual frequency of the dclk and drdy signals if you have some way to do that
<zmatt>
oh and maybe check the kernel log for errors
<Siegurd1>
Ive checked. The CKL line is 8.192 MHz and DRDY Is 128 kHz impulses
<zmatt>
huh that's very strange then
<zmatt>
if the format is right and the frequencies are right then arecord ought to be receiving data at the expected rate
<zmatt>
have you inspected a hexdump of its raw output? that might also give some clue about what's going on
<Siegurd1>
I need to write simple program to scan raw file
<zmatt>
seems okay, apart from the channel order being 02461357
<Siegurd1>
tt may be that (requested = 128000Hz, got = 96000Hz)
<zmatt>
?
<Siegurd1>
so channls are disordered
<zmatt>
the channel order is just because the kernel and the AD7771 evidently have a different idea on how to pack 8 channels into 4 lines x 2 channels/line
<Siegurd1>
oh
<zmatt>
or I should say mcasp and the AD7771
<zmatt>
so that's benign
<zmatt>
so this is really weird
<Siegurd1>
What if just change chanel numbers phisicaly)
<zmatt>
I mean, you can reassign them in hardware or in software whatever is convenient for you, channel ordering is obviously not really important
<zmatt>
what's just really weird is that arecord says it's getting data at a rate that seems to be 96 kHz
<zmatt>
does arecord print that "rate is not accurate" warning immediately or after some delay/
<Siegurd1>
immediately
<zmatt>
it's possible it's just fucking wrong
<zmatt>
and if so then I might know why
<Siegurd1>
it prints it even if AD7771 is turned off
<zmatt>
so I think the kernel *believes* (incorrectly) that the requested rate of 128 kHz can't be configured and 96 kHz is the closest thing, so that's what it configures and reports back to arecord which prints the warning as a result. however there's nothing actually being configured based on the samplerate anyway, like I said the AD7771 is in control of how fast data is being delivered
<zmatt>
so I suspect you're actually still getting data at 128 kHz even though the kernel and arecord mistakenly believe you're recording at 96 kHz
vagrantc has quit [Quit: leaving]
<zmatt>
i.e. you can just ignore the warning
<Siegurd1>
I think you are wright cuz if i set -r 192 there is no warnongs no mather AD7771 is ON or OFF
<zmatt>
but this is why it's important to use -D hw
<zmatt>
since if you were using plug:hw then alsa would have inserted a resampler from 96 kHz to 128 kHz
<zmatt>
which would have resulted in complete garbage output
<zmatt>
(due to that 8-bit header in the most significant bits)
Shadyman has joined #beagle
<zmatt>
and I think the reason the kernel thinks 128 kHz isn't possible will be because of the codec driver we're abusing
<Siegurd1>
you're right again, because otherwise (in plug) the data is filled with some zeros.
<zmatt>
wtf that's not what I would have expected
<zmatt>
anyway, this would probably be fixed with the tdm-audio codec driver but it's way easier to just ignore the warning and let the kernel believe it's 96 kHz ... just a very very very inaccurate 96 kHz clock ;-)
<zmatt>
you can suppress the error by using -r 96 instead of -r 128 ... it won't have any effect anyway
<zmatt>
so those leading zeros are just resampler latency, but the real issue is of course the data
<Siegurd1>
even when -r 10 file size is groving with the same speed
<zmatt>
it sees the 8-bit header as the most significant data bits, and it looks like the resampler they're using actually only produces 16-bit audio output
<zmatt>
so yeah the top 16 bits are garbage and then bottom 16 bits are zero :P
<Siegurd1>
yep
<zmatt>
anyway, it's slightly hacky to let alsa believe it's 96 kHz but it should work fine. just leave some comments in the appropriate places of your project for any future maintainer (including future self) explaining what the heck is going on here ;)
<Siegurd1>
i gues it's all good and now I need to get the data from C program and make aditional checks. Also with signal generator on AD7771 input to check if no data is corrupted
<zmatt>
the really lazy way to interface with alsa would just be having arecord output its data to stdout and then pipe that into your program but that's of course kinda gross and inefficient
<Siegurd1>
))
<Siegurd1>
I'll create a topic on BB forum to highlight the progress