#avr Logs

Sep 24 2019

01:58 AM nabil__ is now known as nabil
02:06 AM gyuma1etyr: Hi there
02:06 AM gyuma1etyr: have some of you been able to RX/TX at the same time with a Software Serial on ATtiny85?
02:52 AM davor_ is now known as davor
07:07 AM Fuchikoma: soreau: So your serial data is garbled. Might be a buffer issue, might be an incorrect baud rate, might be something interfering with the data fetch-and-send (e.g. race condition/interrupt interference as suggested)
07:08 AM Fuchikoma: Baud rate is easiest to check by just tweaking it up and down and see what happens, absent of a logic analyzer or scope to actually measure it
07:10 AM soreau: Fuchikoma: There's no baud rate involved. It's audio device class which means it appears to the system as an audio input, such as a microphone
07:11 AM Fuchikoma: You're transmitting digital data over a serial link (one wire to transmit). There is a baud rate
07:11 AM cehteh: soreau: just step back, make it much simpler, test single parts, generate sound with a sampling rate of 4khz or lower, check that
07:11 AM soreau: Well in this case, it's called sample rate
07:11 AM cehteh: until you have a working version
07:12 AM Fuchikoma: No, it's called baud rate
07:12 AM cehteh: then scalle it up with single steps, when it breaks debug what you changed last
07:12 AM Fuchikoma: The bytes are the samples. To transmit the bits in each byte, there needs to be an agreement of what constitutes a "1" or a "0"
07:17 AM Fuchikoma: Looking at some randome search results, it sounds like you need to be transferring data much faster than once every millisecond. This page is basically saying you need a transfer every 125 microseconds; https://www.edn.com/design/consumer/4376143/Fundamentals-of-USB-Audio
07:18 AM Fuchikoma: That alone may be the source of your problems, if this is what's happening
07:23 AM cehteh: my first step for anything timing critical and reliable would be not to use any arduino related software :D
07:23 AM cehteh: making that stuff async timer driven, producer/consumer
07:37 AM nohit: there's no concept of baud rate regarding usb (audio) devices
07:37 AM soreau: Fuchikoma: for full-speed it's 1 packet per ms
07:37 AM soreau: for high-speed it's 125 microseconds
07:38 AM Fuchikoma: How many samples are you sending each ms?
07:38 AM soreau: 16 samples, 16 bits each (so 32 bytes)
07:39 AM soreau: cehteh: I'm not ignoring you btw, you're giving me an idea
07:40 AM nohit: with ST's own tools this would probably be quite easy
07:40 AM soreau: nohit: yea but no composite support
07:40 AM soreau: I've explored ST, stm32duino, mbed and keil
07:42 AM vmt: what do you mean by KEIL?
07:42 AM nohit: are you sure CubeHAL dont have composite support ?
07:42 AM vmt: also *duinospruinoeasdfsdauinos you can forget flat
07:42 AM Fuchikoma: 16000 samples per second stereo, or 32000 samples per second total, right?
07:42 AM vmt: and mbed, too
07:42 AM vmt: that would be correct
07:43 AM vmt: though
07:43 AM cehteh: you may look at freertos or similar as well
07:43 AM vmt: it really depends on the definition of a sampole
07:43 AM soreau: nohit: I'm mnot absolutely sure but from my tests and readings, I have found it simply does not support it. When I tried, the last device registered wins
07:43 AM vmt: sample, even
07:43 AM Fuchikoma: sample being a value from the ADC
07:44 AM vmt: sure
07:44 AM Fuchikoma: (As I understand it, anyway)
07:44 AM soreau: Fuchikoma: sure
07:45 AM nohit: soreau: have you checked this https://www.st.com/en/embedded-software/x-cube-usb-audio.html ?
07:45 AM Fuchikoma: So if you're doing 32000 samples per second, and each sample is 16 bits, it's that 512,000 bits (64,000 bytes) per seond, and you should be sending 64 bytes per millisecond?
07:45 AM Fuchikoma: isn't*
07:46 AM soreau: nohit: yes but again, there's no composite support. I want to have audio device class + communications device class
07:46 AM nohit: ok sorry i was wrong, that is true
07:46 AM nohit: no composite support
07:47 AM soreau: Fuchikoma: no
07:47 AM soreau: Fuchikoma: you're multiplying by 2, twice
07:48 AM soreau: Fuchikoma: Also I have tried sending twice as much and half as much but it just changes the frequency of the problem
07:48 AM nohit: https://github.com/IntergatedCircuits/USBDevice
07:49 AM nohit: STMicroelectronics STM32 using the STM32_XPD peripheral drivers or the STM32CubeMX package with this wrapper project
07:49 AM Fuchikoma: So they're not 16 bit samples, it's two 8-bit samples
07:49 AM vmt: which would make them 8-bit samples, then
07:49 AM soreau: Fuchikoma: yes, sorry if I wasn't clear on that
07:49 AM Fuchikoma: k
07:50 AM nohit: "This is a simple example project stub which serves as a starting point to integrate the USBDevice library into an STM32CubeMX project."
07:50 AM nohit: i would use that
07:51 AM nohit: ST's own tools rule
07:51 AM vmt: and what cehteh said, simplify it, make it work, and then ramp it up
07:51 AM soreau: but in the descriptor, you define the samples in number of bits for total number of samples per AN295
07:51 AM soreau: in each subframe
07:51 AM vmt: soreau: but the traditional nomenclature is, oh you know, sample size being sample size.
07:52 AM soreau: vmt: Are you saying AN295 is wrong or I misread it somehow?
07:52 AM vmt: i'm not saying anything is wrong. they just use their own definition of it, then
07:53 AM vmt: it doesn't matter whether you have 1,2 or 16 channels. the sample size is the size of a single sample
07:57 AM soreau: well, you guys might be onto something
07:57 AM vmt: it's just that the data is usually interleaved LRLR so the "subframe" or whatever they use to describe it, consists of a L and R byte (sample)
07:58 AM vmt: but then we can go on to the semantics of what exactly is meant by a sample, as i already said
08:02 AM soreau: vmt: ah, it's defined by bNrChannels
08:02 AM soreau: bNrChannels = 0x02 "This field tells the host that the samples represent a left and a right signal."
08:05 AM soreau: nohit: I might have to look into it
08:16 AM soreau: cehteh: FWIW, even at 4000 sampling rate, it's the same problem
08:17 AM cehteh: thats a start
08:18 AM cehteh: try 100 or the slowest possible/supported ,,, prolly the problem remains, but with that you can debug your code, where is the problem
08:19 AM cehteh: data race or whatever
08:19 AM cehteh: i wont wonder if its some stupid error in your code :D ... been there too
08:19 AM nohit: seems like easy to use https://github.com/IntergatedCircuits/USBDevice4Cube
08:25 AM cehteh: do you sample into a ring buffer, double buffering, dma or how?
08:26 AM cehteh: you tried sending 'synthesized' data and that had still problems?
08:26 AM cehteh: just pin down the bug, find out what happens
08:30 AM soreau: cehteh: yes I tried sending both real data (from analogRead->user buffer->copy to pma in response to host request) and to simply copy some consistent data in the request handler and comment out the rest of the code
08:30 AM cehteh: uding analogRead for continous sampling is the most stupid idea ever :D
08:31 AM soreau: cehteh: it's to get 'real' test data
08:31 AM soreau: as opposed to sending random or something
08:31 AM cehteh: still bad
08:31 AM soreau: either way, it's not a problem
08:31 AM cehteh: but will make problems later
08:31 AM soreau: not when I rip it out
08:32 AM soreau: and replace with adc
08:32 AM cehteh: anyway geneate a sawtooth by just incrementing the sample value
08:32 AM soreau: cehteh: I did
08:32 AM cehteh: ok
08:32 AM soreau: I get garbage on the other end
08:32 AM cehteh: dont care about the rest ... makew that work
08:32 AM soreau: seemingly random values
08:32 AM cehteh: rest==adc sampling
08:32 AM cehteh: yes
08:32 AM soreau: cehteh: if I could make that work, I'd be ahead of the game
08:33 AM cehteh: way to go :)
08:33 AM soreau: but of course I'm just assuming how a wav file looks in hex
08:33 AM cehteh: hex doesnt matter at all
08:33 AM soreau: it's a header followed by packed samples, right?
08:34 AM cehteh: dunno ... its your job not mine
08:34 AM soreau: true..
08:35 AM cehteh: when its completely random you doing something very wrong
08:35 AM cehteh: out of bounds access, syncronization whater
08:35 AM cehteh: otherwise can happn that data is not endianess correct then you notice that bytes are swapped on a sawtooth
08:36 AM cehteh: (but normal musig will look pretty random)
10:03 AM soreau: cehteh: I just happened to notice something by sheer coincidence (because I had the ghex window resized to a certain size so when I scrolled, it was obvious there was a repetition).. the data I am getting does repeat for the sawtooth test but there are no 0 values.. (sending 0-255 then back to 0 and repeat)
10:03 AM * soreau counts the bytes
10:05 AM soreau: it's getting 160 bytes each repeat, though I'm sending 512
10:05 AM cehteh: do you even send the right data :)
10:05 AM soreau: cehteh: Do you want to check my send function?
10:06 AM soreau: s/check/see/
10:06 AM cehteh: no, i want you to think about it
10:06 AM cehteh: do you use doublebuffering or a ringbuffer or what? how do you sync access to it, do you use any casts and fuck with pointers?
10:06 AM soreau: I don't see how I could be sending wrong data though it's double buffered, I have tried single buffering
10:07 AM cehteh: how do you synchronize access to the buffers
10:07 AM soreau: dtog_rx
10:07 AM cehteh: and hey just send all zeros does that work, guess not
10:07 AM cehteh: dtog_rx?
10:08 AM soreau: per RM0008
10:08 AM soreau: isochronous section
10:08 AM soreau: let me try all zeros
10:09 AM cehteh: no idea what that is but your code needs to sychronize access to buffers somehow, once a buffer is fillted it needs to be shipped and next buffer shoulnt be written before it old content are send
10:09 AM soreau: yes that's what it does
10:09 AM cehteh: obliviously not :)
10:09 AM soreau: it tells me which buffer is in use by the usb peripheral, and I use the other one
10:09 AM cehteh: well send all zeros and see
10:10 AM soreau: ok
10:13 AM soreau: no 0's in sight, I get the same data repeated
10:13 AM soreau: as in the sawtooth test
10:14 AM cehteh: so you send some completely different data for some reason
10:14 AM cehteh: fix that
10:14 AM soreau: the weird thing about the PMA in stm32 is that you only get to use 16bits each 32bits.. it's 32bit aligned but you only get to use half of that
10:15 AM soreau: so maybe I'm shoveling data in wrong portion
10:15 AM cehteh: no idea what you are doing, but whatever you do its wrong :)
10:15 AM soreau: not necessarily.. it could be a bug in libmaple because I seem to be the first user of this isochronous and double buffer code
10:18 AM cehteh: maybe
10:18 AM cehteh: but would surprise me
10:19 AM soreau: but apparently my pointers to the pma are wrong or something
10:19 AM * soreau tries single buffering
10:20 AM cehteh: double buffering is prolly the way to go, but you do something wrong there
10:20 AM cehteh: maybe sending only one single buffer exposes the problem
10:21 AM cehteh: anyway you need to hone your debug skillz
10:24 AM soreau: now I'm getting some zeros
10:24 AM soreau: but not all zeros.. huh
10:24 AM cehteh: lolz
10:25 AM cehteh: add sawtooth
10:25 AM nohit: cehteh: oh really? isnt the consensus on this channel that you debug by looking at the code
10:25 AM nohit: ;)
10:26 AM soreau: so I get 15 0's then 15 garbage(?) and repeat
10:26 AM soreau: bytes of each
10:27 AM soreau: seems like it should be 16
10:27 AM nohit: just dont write any bugs and youre good
10:28 AM soreau: heh
10:28 AM soreau: unless the bug is already in the library you're using
10:29 AM soreau: oh maybe I'm doing math wrong
10:29 AM soreau: oh right it is 16 and 16
10:30 AM soreau: ok at least that kinda makes some sense
10:30 AM nohit: with double buffering ?
10:30 AM soreau: no
10:30 AM cehteh: dont blame others fix your code :D
10:30 AM soreau: nohit: with single
10:30 AM cehteh: well maybe debug that lib
10:30 AM soreau: so let me try doubling the write amount
10:31 AM cehteh: with a sawtooth you should exactly see at what values it gets wrong
10:31 AM cehteh: is that somewhere at some package boundary, etc
10:31 AM soreau: cehteh: well the 0 test has to pass first
10:31 AM soreau: otherwise I don't know what I'm getting
10:32 AM soreau: damn, doubling the write helps.. I get all 0's
10:32 AM nohit: doubling the write ?
10:32 AM soreau: nohit: well, doubling what I write to the PMA
10:33 AM soreau: I mean it's not simple.. I have to write to PMA, then set tx count. And the PMA has to be accessed by 32bit boundary but you can only write 16bits of the 32
10:33 AM soreau: but it used to be simple in my head until now
10:34 AM soreau: now sawtooth
10:34 AM cehteh: you prolly have some sync issies, writing addresses in the wrong order, dont waint for the hardware to be finished with the buffer etc
10:35 AM soreau: cehteh: but that wouldn't be my fault
10:35 AM soreau: maybe the writing part
10:35 AM cehteh: no idea
10:35 AM soreau: but let me see this sawtooth
10:35 AM cehteh: well gut feeling: it might be your fault :)
10:36 AM soreau: heh
10:37 AM soreau: now when I try saw tooth, I am getting values all over the place
10:38 AM cehteh: glhf to figure out what happens there
10:38 AM soreau: but I see a repetition
10:39 AM cehteh: endianess issue? how many bits per sample?
10:39 AM cehteh: try a sawtooth from 0-255
10:39 AM soreau: I am
10:39 AM soreau: 16 or 8 bits per sample, depending on how you look at it
10:40 AM cehteh: congrats for inventing a poor random generator
10:40 AM Fuchikoma: Even if it's an endianess problem, you'd still see a clear pattern
10:40 AM soreau: but this isn't the problem
10:40 AM soreau: the actual data has nothing to do with the fact that it takes 4x as long to record as it does to play back
10:41 AM Fuchikoma: Maybe it does, though
10:41 AM soreau: so I tell arecord to record 5 secs and it takes exactly 20, but aplay plays it in 5, really fast
10:42 AM soreau: and every 640 it repeats, in this sawtooth test
10:42 AM Fuchikoma: How does the receiving end know what the sample rate and bit depth is?
10:42 AM soreau: single buffered
10:42 AM Fuchikoma: Hard coded?
10:42 AM soreau: Fuchikoma: the descriptor
10:42 AM soreau: usb descriptor information
10:42 AM Fuchikoma: So the sending device sends the descriptor for the data to the receiving device?
10:42 AM soreau: yes
10:42 AM Fuchikoma: ...and the data received is a hot mess?
10:43 AM soreau: well.. yea
10:43 AM Fuchikoma: So have you checked that the decriptor data makes it through properly?
10:43 AM soreau: Fuchikoma: absolutely
10:43 AM soreau: lsusb -v gives quite a clear picture, and if anything is wrong, it wont even show up as an audio device
10:44 AM soreau: I've scrutinized the descriptor many times
10:44 AM Fuchikoma: But you've checked that the receiver is using the proper bit depth, sample rate, field order etc
10:44 AM Fuchikoma: okay
10:44 AM soreau: yes
10:45 AM soreau: also pulseaudio detects this information correctly
10:45 AM soreau: it's just that the device isn't living up to what it says it's going to do
10:46 AM Fuchikoma: What happens if you lie in the descriptor?
10:46 AM soreau: To what extent?
10:46 AM cehteh: see this as isolated problems for now, tackle one after another, first sending the correct data, second at correct speed/samplerate
10:46 AM Fuchikoma: Tell it your data is, say, 4k samples/sec instead of 16
10:46 AM soreau: like set sample rate to 4000 and send it as if it's 16000?
10:47 AM cehteh: maybe they are related, and fixing one reveals/fixes the other, but you need to figure out whats going wrong
10:47 AM Fuchikoma: mmm
10:47 AM soreau: well in my sawtooth test, maybe it's an endian issue
10:48 AM Fuchikoma: That's easy to check if you have the raw data
10:48 AM Fuchikoma: Can you pastebin some of it?
10:49 AM soreau: sure, let me figure out how
10:49 AM soreau: I don't think it's endian now that I look again
10:49 AM soreau: let me try to post the raw file somehow
10:50 AM soreau: https://filebin.net/rnfgagnhn6u7yuhy
10:50 AM cehteh: sending only 0-255 shouldnt have endianess issues
10:50 AM soreau: cehteh: I'm sending 0-255, then back to 0 and repeat..
10:50 AM soreau: and recording with S16_LE
10:51 AM cehteh: try 0-127 ... to eleminate sign issues as well:D
10:51 AM soreau: but really, it's not the data that's the issue, it's the fact that it doesn't send enough data somehow
10:52 AM cehteh: ok then fix that
10:52 AM soreau: I've tried sending more but with PMA constraints, it doesn't make much sense
10:53 AM soreau: but I could try Fuchikoma's suggestion about 4k and see what happens
10:53 AM soreau: (again)
10:53 AM cehteh: 'trying' is the wrong way ... figure out systematically whats going wrong
10:54 AM soreau: right
10:54 AM soreau: Fuchikoma: that definitely doesn't work
10:55 AM soreau: I can't record anything, there's no volume meter in pavucontrol or anything
10:55 AM soreau: same thing that happens if I try sending more data at 16000
10:59 AM Fuchikoma: k
11:01 AM soreau: so with double buffered (doesn't matter what I send), data repeats every 160 bytes and with single buffered sawtooth test it repeats every 640 times, which is exactly 4 times as much
11:01 AM Fuchikoma: With this data; you're sending 0-255 for both channels at the same time?
11:01 AM soreau: idk if this has any relevance but it's interesting nonetheless
11:01 AM soreau: Fuchikoma: yes just blindly sending 0-255 and back
11:02 AM soreau: so it would be 0 for left, 1 for right, 2 for left, etc.
11:02 AM Fuchikoma: aha
11:02 AM soreau: but in wav file, I think it's just packed data
11:02 AM soreau: so it shouldn't matter
11:02 AM Fuchikoma: Well there's almost a pattern, then
11:04 AM Fuchikoma: For one, if you're sending 0x00, 0x01, 0x02, 0x03 etc
11:05 AM Fuchikoma: But the data as received is counting down, not up
11:05 AM soreau: What do you mean counting down?
11:05 AM soreau: it's not really in succession afaik
11:06 AM Fuchikoma: It should be in succession should it not?
11:06 AM soreau: well yea but that's kinda the problem, it isn't
11:06 AM Fuchikoma: Let's remove one more level of fuckery; send the same value for both channels
11:06 AM soreau: ok
11:07 AM Fuchikoma: That will eliminate any possible interleaving shenanigans maybe
11:07 AM Fuchikoma: but I see values like: CE CD CC CB CA CD C8 C7 C6 CD C4 CB C2 CD C0 and that's clearly counting DOWN, not up
11:08 AM Fuchikoma: Though it's strange that there's a "CD" where there ought to be a "C5" in that sequence
11:08 AM Fuchikoma: And another CD where there ought to be a C1
11:08 AM Fuchikoma: and C9
11:09 AM Fuchikoma: In fact there's an errany "CD" every 4 bytes, which is a nice coincidence if you're sending 4 bytes per frame don't you think?
11:10 AM soreau: Fuchikoma: yea and I think the problem is in libmaple
11:12 AM soreau: oh I am doing a triangle wave
11:12 AM soreau: not sawtooth
11:12 AM soreau: so it's not surprising it counts down
11:12 AM soreau: let me fix that too
11:12 AM Fuchikoma: ffs
11:15 AM soreau: Fuchikoma: https://filebin.net/wwj76r382qwcjtfl
11:15 AM soreau: sorry bout that
11:18 AM Fuchikoma: So one full "cycle" should be 256*2 = 512 bytes
11:18 AM soreau: with the triangle case but with the sawtooth case it should be 256
11:19 AM Fuchikoma: Well you count 0 to 255, and each value should be output twice (right and left channels) no?
11:19 AM soreau: oh
11:19 AM soreau: well yes
11:19 AM Fuchikoma: I'm looking at it in a hex editor and I immediately see that the pattern is not repeating properly
11:21 AM Fuchikoma: Stripping off the header, I should see the same pattern at offset 0x0000 and 0x0100
11:22 AM Fuchikoma: But I don't
11:22 AM soreau: It seem to repeat at 510, not 512, starting at the first 00, 00 pair and adding 512 to offset, I end up at 02, 02
11:22 AM Fuchikoma: No
11:22 AM soreau: no?
11:22 AM Fuchikoma: The pattern repeats, but every time it does the entire sequence is shifted up by 1
11:23 AM soreau: well I don't see any FF's
11:24 AM Fuchikoma: There are also no 00s
11:24 AM soreau: yes there are
11:24 AM Fuchikoma: Not where they ought to be
11:24 AM soreau: but sometimes it goes FE->00 and sometimes FE->10
11:25 AM Fuchikoma: The very first value in the sequence out to be 0x00 (or maybe 0x01 depending on how you wroite it)
11:25 AM Fuchikoma: But it's 0x2F
11:25 AM soreau: but is that surprising?
11:25 AM soreau: because I start the recording at an arbitrary time
11:26 AM soreau: it's not going to wait to start when I start recording
11:26 AM soreau: it's already data in flight
11:26 AM Fuchikoma: ffs
11:26 AM Fuchikoma: tell me these thngs :/
11:26 AM soreau: that's the nature of recording any usb device
11:27 AM soreau: it's not like it's waiting for something to connect, the kernel driver is already doing it's thing after the device is enumerated
11:28 AM Fuchikoma: okay well, let's go to the first 0x00 0x00 and assume that's the start fo the next cycle
11:28 AM soreau: yes that's what I did
11:28 AM soreau: and when I added 512, I got to 02,02
11:29 AM Fuchikoma: Yup, so you're not making it to 255
11:29 AM soreau: ok let me see if I can off-by-one this thing
11:30 AM Fuchikoma: It also goes 00, 11, 12, 13, 14 ... 1F, 20, 31, 32, 33
11:31 AM soreau: and it goes FE, 10 sometimes
11:34 AM Fuchikoma: Every time the low nybble is 0, the entire byte is increased by 0x11 instead of 0x01
11:35 AM soreau: Fuchikoma: that's an interesting observation
11:36 AM soreau: oh hm
11:37 AM soreau: damn this damn alignment
11:37 AM soreau: erm.. this PMA alignment
11:38 AM soreau: no my code should work
11:40 AM soreau: Fuchikoma: but I think it's not that it's incremented but the device just fails to send these missing bytes
11:40 AM Fuchikoma: Could be
11:41 AM soreau: because it's not a matter of wrong data so much as it is only getting like 1/4 of the data it should
11:41 AM soreau: which of course causes wrong data
11:43 AM Fuchikoma: https://pastebin.com/9GWxCDys
11:43 AM Fuchikoma: okay so
11:43 AM Fuchikoma: Here's a new hypothesis
11:44 AM Fuchikoma: Are there any control characters/reserved values in the isochronous data stream protocol?
11:45 AM soreau: Fuchikoma: no, it's just raw data
11:46 AM soreau: afaik at least
11:46 AM soreau: I have yet to read anything that says anything like this
11:46 AM Fuchikoma: In the pastebin I just aligned the data like you'd expect to see it
11:46 AM Fuchikoma: 32 bytes (16 values) per line
11:47 AM Fuchikoma: Every time the sequence hits 0xFF, the 0xFF itself is eaten and the missing 16 values gets offset by 1
11:50 AM soreau: Fuchikoma: but it might be missing like 3 iterations of the sawtooth
11:50 AM Fuchikoma: I stopped after the first 512 bytes but maybe there's another problem further in
11:52 AM soreau: well I'm saying you might not be seeing the whole picture
11:52 AM soreau: because.. it isn't there :P
11:52 AM Fuchikoma: Clearly there is data missing :p
11:53 AM _abc_: I think you discovered one end uses a data compression protocol and the other does not understand it
11:53 AM _abc_: Or has a programming error.
11:54 AM soreau: _abc_: But the descriptor is declaring it as raw PCM
11:54 AM Fuchikoma: There's no compression
11:54 AM soreau: yea there's no codecs or anything involved AFAIK
11:54 AM _abc_: soreau: perhaps one end gets confused? Do you see any framing errors or such?
11:54 AM soreau: _abc_: nothing in dmesg if that's what you're asking
11:57 AM soreau: The thing I wonder is if there's code that is copying from PMA or if it's done in hardware and controlled by registers
12:01 PM Fuchikoma: Well at least there's a pattern so that's something to work with
12:01 PM soreau: but yea, reading code and not having printf at disposal (my fav debug tool) kinda slows things down
12:02 PM soreau: Fuchikoma: yes, though that leaves double buffering todo
12:02 PM Fuchikoma: This is single buffered?
12:02 PM soreau: yes
12:02 PM Fuchikoma: So you're writing data to the buffer and the library sends it?
12:03 PM soreau: that's the idea
12:03 PM soreau: maybe we're using it at the same time
12:03 PM Fuchikoma: But is that what you're doing now?
12:03 PM soreau: but the 0 test failed with double buffer
12:03 PM soreau: Fuchikoma: yes this is with single buffering
12:04 PM Fuchikoma: Well I'm thinking if half the data is missing maybe it's doign something fucky with the other buffer
12:04 PM Fuchikoma: even though it shouldn't be
12:04 PM soreau: Fuchikoma: But even if the data was totally garbled, I'd be fine with that if it sent it at a consistent rate
12:04 PM Fuchikoma: mmm
12:04 PM cehteh: as i saied, sync issues, data races .. but concentrate on one thing, divide and conquer
12:04 PM soreau: i.e. taking 5 secs to record 5 secs of audio
12:05 PM soreau: but it takes exactly 4 times as long
12:05 PM cehteh: soreau: settle for either, fixing datarate or fixing data ..
12:05 PM cehteh: i'd go for correct data first
12:05 PM soreau: cehteh: I want to fix the transfer rate first
12:05 PM soreau: because I think that's the crux
12:05 PM cehteh: well then figure out why its wrong
12:05 PM soreau: I'm reading
12:05 PM Fuchikoma: They *could* be related issues, but at least you can SEE the missing data problem
12:06 PM cehteh: *exactly* 4* as slow or only approximately?
12:06 PM soreau: exactly from my tests
12:07 PM soreau: I time it by starting on even number of seconds on a clock and wait for it to finish
12:07 PM cehteh: say you seen 8 bit samples mono ... but its configured 16bits stereo .. that maks a factor of 4 for example
12:08 PM soreau: cehteh: yea but if I try to send more or lower the sample rate, things just quit working altogether
12:09 PM cehteh: rtfm .. i wont expect that "trying" solve the problem, there may be other things to configure/set up to make it work correctly
12:10 PM cehteh: some usb protocol analyzer might help as well
12:10 PM cehteh: just sampling doesnt tell you much about the format/cvonfiguration of the USB port or?
12:11 PM cehteh: iirc you can make the linux kernel chatty about this things
12:11 PM Fuchikoma: I'm not sure the problem is in the physical layer
12:11 PM cehteh: otherwise logic analyzer, which might be a bit tedious becasue its relatively fast and lots of data
12:11 PM vmt: ...you mean expensive
12:12 PM cehteh: nah layer above that maybe .,. configuration of the transfer parameters
12:16 PM cehteh: then filling buffer and sending are not in sync which results in garbled data ...
12:17 PM cehteh: i asked before how you sync that
12:24 PM polprog: the other day i got 80 SOIC ULN2803A
12:25 PM polprog: two tubes
12:25 PM polprog: how many robotz could rue_bed make out of them?
12:25 PM cehteh: :)
12:26 PM polprog: also found the flash chip for the compaq io board
12:26 PM polprog: literally turned the whole lab upside down... i thought it vanished
12:27 PM PoppaVic: polprog: wait, lemme guess: cat decided to steal the dead-bug? ;-)
12:27 PM polprog: nah
12:27 PM polprog: it was put into an envelope made out of receipt and tape
12:27 PM PoppaVic: I had to stop leaving partial builds exposed
12:27 PM polprog: and the envelope curled in a way that obstructed the label i made on it...
12:27 PM PoppaVic: ...thinks missing? walk around - you'll step on it eventually ;-)
12:28 PM polprog: time to flash the new old LSI bios, and test if the card works
12:28 PM polprog: because the issue is that the card boots only on ProLiants because of the SCSI controller bios
12:29 PM polprog: so if you want to boot it in a different machine, you have to remove the scsi bios
12:29 PM polprog: which renders the SCSI controller unusable
12:29 PM vmt: i fried the power side of my old stinkpad a few months ago, i finally ordered a new one
12:29 PM PoppaVic: Lovely.. Great design
12:30 PM polprog: if this works, ill have a 100BASE-T ethernet, ATI Rage IIC and a SCSI controller on one PCI card!
12:30 PM polprog: PoppaVic: thats because Compaq made their custom bios
12:30 PM polprog: https://www.vogons.org/viewtopic.php?f=46&t=66953
12:31 PM vmt: ati rage... oh noes. legacy ff pipeline
12:34 PM polprog: what pipeline?
12:35 PM vmt: fixed function
12:36 PM polprog: sounds interesting
12:36 PM polprog: i dont know much about gpu design
12:37 PM vmt: well i don't even know if rage2 does transform and lighting
12:37 PM vmt: most likely not
12:39 PM vmt: and it's not so much gpu design as it is api design, though some things are reflected
12:40 PM vmt: basically what the fixed function pipeline means, is that prior to the paradigm switching to shaders, there were a number of ways in which you could transform, clip and shade your pixels
12:41 PM vmt: and they were functions, which controlled parameters for clip, transform and lighting respectively
12:41 PM vmt: there, even
12:41 PM vmt: now with shaders all bets are off and you just upload whatever data and massage it with shaders all you want
12:42 PM vmt: and the term fixed function pipeline refers to the APIs, not the actual hardware implementation (or driver fuckery in-between)
12:43 PM vmt: namely that of D3D and opengl
12:43 PM polprog: ok
12:43 PM polprog: so before shaders you had to write per-card subroutines for graphics if you wanted to use GPU acceleration, right?
12:46 PM Helle_: That is even before that
12:46 PM vmt: yes
12:47 PM vmt: the era i'm talking about is when drivers take care of the implementation but conform to the api
12:47 PM Helle_: but you couldn't manipulate per pixel in a sensible fashion, you had a bunch of standard functions you could turn on or off or set a parameter on
12:47 PM polprog: ah
12:48 PM Helle_: Having never done graphics programming in that era, it sounds like utterly painful as even quite basic effects required you to misuse the functions
12:48 PM vmt: yes
12:49 PM vmt: however, the apis still have manufacturer-specific extensions
12:49 PM * Helle_ started with OpenGL when 2.1 was out and hence simple shaders where a thing on even cheap hardware
12:51 PM vmt: thankfully now we don't have such variety of mainstream gpu manufacturers nor insane fans of legacy hw (apart from polprog), so gpus aren't all that big of a pain to work with
12:59 PM polprog: lol
01:10 PM soreau: So with usbmon+wireshark, I see the host sends an urb every ms but the device doesn't respond until a whole ms later and as soon as it gets the response, it sends another urb. However, it's only sending a data payload every other packet. So every 2ms, the host gets 112 byte packet with data, the others are 80 (missing the 32 byte payload)
01:11 PM soreau: That doesn't really explain why it takes four times as long to record though
01:15 PM soreau: but each data payload is missing 17 bytes in between, so for instance one ends at d4 and then the next 2ms later starts at e5
01:15 PM soreau: and this is consistent
01:16 PM soreau: well I guess it would be 17*2
01:16 PM soreau: which is 34, a bit closer to what's missing
01:20 PM soreau: again I think I'm doing math wrong
01:21 PM soreau: yea it's just missing every other data payload of 32 bytes
01:21 PM soreau: now let me look at double buffered case again
01:29 PM soreau: hey, I made some progress apparently.. now it only takes 10 secs to record 5 secs..
01:30 PM soreau: but now it's sending 64byte payload every 2ms
01:30 PM soreau: still missing a payload per frame
01:30 PM vmt: seriously though, why are you complicating this with usb and other things while you haven't even gotten the data acquisition part down, apparently?
01:30 PM soreau: vmt: what do you mean?
01:30 PM vmt: i mean what i said
01:31 PM soreau: vmt: Well I don't understand what you're talking about
01:31 PM soreau: I guess you haven't been following along or I don't understand what you mean
01:31 PM vmt: i've been following you on and off
01:33 PM vmt: you're buffering some data sampled from an adc, correct?
01:33 PM soreau: no
01:34 PM vmt: no?
01:34 PM soreau: I'm sending consistent sawtooth wave generated
01:34 PM vmt: so have you verified that your data acquisition is correct
01:34 PM soreau: I don't know what you mean by that
01:35 PM vmt: in this case, you're generating your data, so is that correct?
01:35 PM soreau: is it correct at what point?
01:35 PM soreau: it's correct at the point I generate it
01:36 PM vmt: you have verified it?
01:36 PM soreau: On the other end I'm using arecord to create a wav and now I'm looking at the raw packets using usbmon and wireshark
01:37 PM soreau: and things aren't adding up but they're consistent
01:37 PM vmt: so instead of blindly poking around in the receiving end, where is your problem located them?
01:37 PM soreau: in libmaple
01:37 PM vmt: you have verified this?
01:37 PM soreau: no
01:37 PM vmt: ...
01:37 PM soreau: it's my best educated guess
01:38 PM vmt: debugging-by-guessing is a true and tested method for success
01:38 PM vmt: also why are you using libmaple in the first place? it's for -cm3, use stdperiph.
01:39 PM soreau: I don't know what you mean by that
01:39 PM soreau: libmaple/stm32duino is what has allowed me to get the furthest with what I want to do
01:39 PM vmt: yet you keep *guessing* the bug is in "libmaple"
01:39 PM vmt: whatever the fuck that does then...
01:39 PM soreau: but now I'm a bit oc trying to figure out the problem in this scenario
01:40 PM vmt: generating a sawtooth wave and sending it through USB shouldn't exactly be hard just using the st stdperiph library
01:40 PM vmt: it's deprecated, but it's nicer to work with than HAL
01:40 PM vmt: that is to say, if you're *certain* the problem is in "libmaple"
01:41 PM vmt: other things may or may not include generating the data, buffering the data, or just sending it
02:10 PM nohit: "use stdperiph"
02:10 PM nohit: who's the legacy guy now ?
02:10 PM nohit: ;)
02:12 PM nohit: soreau: if you hit a wall at some point, try out what i linked earlier
02:12 PM nohit: STM32CubeHAL and that's USBDevice library
02:12 PM nohit: -'s
02:12 PM soreau: nohit: yes I have been thinking about it but does that permit the device to be composite audio device class+cdc?
02:13 PM nohit: yes
02:13 PM soreau: nohit: I think I want to file a bug for this problem first
02:13 PM nohit: not HAL, but that USBDevice library
02:13 PM nohit: yeah
02:14 PM nohit: btw why do you need cdc also ?
02:16 PM nohit: iirc this was some device that you connect to your headphones
02:17 PM cehteh: vmt: i suggested soreau to get one part right after another, first starting with synthezized dataand confirm that the data transfer is correct (but also noted that it doesnt matter where to start, as long focussing on fixing one thing at a time)
02:18 PM cehteh: imo getting data correct transfered is a good start anyway becasue thats the most easy way to verify and validate
02:18 PM soreau: nohit: I want to control the device that's emitting the audio
02:25 PM cehteh: soreau: also before filing a bug you should be sure there is a bug :)
02:26 PM soreau: cehteh: well it'd be more of a question in a github issue since there's no 'question' category to file
02:28 PM soreau: I just don't understand why when I rely on dtog, I get 32 extra bytes data in payload and toggling using a variable gives the expected 32, but the first 32 bytes is obviously set by the sawtooth data but it doesn't change.. so the first 32 bytes are always the same (0x21-0xb5) and the rest change, but still it's only sending a packet every other frame
02:29 PM soreau: so confused
02:32 PM cehteh: i dont know your code nor the apis's you use
02:32 PM soreau: me netiher, apparently :P
02:32 PM cehteh: that might be the problem
02:33 PM vmt: cehteh: on an stm32 data generation is really the easiest to validate
02:33 PM vmt: because you have easy ocd
02:33 PM vmt: stlink, openocd and gdb
02:33 PM soreau: but really, it's https://github.com/rogerclarkmelbourne/Arduino_STM32/tree/master/STM32F1/libraries/USBComposite I'm adding to
02:33 PM cehteh: i didnt except that to fail
02:34 PM soreau: vmt: care to elaborate on that?
02:34 PM soreau: I have all of those except gdb
02:34 PM * soreau goes to get the right version
02:34 PM cehteh: soreau: i am more concerened about your code :D
02:34 PM soreau: cehteh: well if I file a report, it will become public
02:35 PM vmt: soreau: the arm gdb should be in the arm toolchain you undoubtedly have
02:35 PM cehteh: reduce your problem to an example with less than 50 lines of code
02:35 PM soreau: cehteh: if I could do that, I could solve it myself
02:35 PM vmt: soreau: you can easily do on-chip debugging (aka. REAL debugging) with an stm32
02:35 PM soreau: vmt: what do you mean?
02:35 PM vmt: you're big on asking what do people mean, yes?
02:36 PM vmt: what's unclear about my statement?
02:38 PM cehteh: what do you use? the usbgenerioc stuff i dont see anything about audio there
02:43 PM soreau: cehteh: You mean in that link?
02:43 PM cehteh: yes
02:43 PM soreau: I am implementing audio class using that as a base
02:43 PM cehteh: isnt there one readily available
02:43 PM soreau: no
02:44 PM vmt: /arduino_stm32/
02:44 PM vmt: lol
02:46 PM cehteh: yup
02:46 PM soreau: ok now I have gdb
02:46 PM soreau: but I doubt it will help anything
02:47 PM vmt: you need the gdb from the arm toolchain...
02:47 PM soreau: well not in 2019
02:47 PM soreau: just gdb-multiarch
02:47 PM vmt: oh, sure
02:47 PM soreau: but I don't even know how I can use it to help anything
02:48 PM vmt: you know how to set it up?
02:48 PM soreau: I read some guides but haven't tried it yet
02:48 PM cehteh: 1. toss away any arduino traces
02:48 PM cehteh: 2. start over
02:50 PM vmt: soreau: well basically you start an openocd server with a device config, it will connect to the mcu via stlink. you can reset and halt the chip. you connect to the openocd's gdbserver and that's it
02:51 PM Fuchikoma: 3. write it in assembler
02:51 PM cehteh: lol
02:51 PM vmt: you can specify the port the server uses or pipe it
02:52 PM vmt: however the internet is littered with tutorials for that so it shouldn't cause any problem to set up
02:53 PM cehteh: either way arduiino is a lost cause when it comes to reliability, error handling and debugging, you may peek at the shit from outside using gdb, but that doesnt improve it
02:53 PM vmt: however #2, gdb's both frontends are heavily from the 1980s and really no-one enjoys using them, apart from cool hacker kids who think things are cooler when ran in terminal emulators
02:53 PM vmt: so i suggest a proper frontend. the only proper one to especially visualize data is eclipse... sadly
02:54 PM vmt: it has a standalone debugger frontend which is slightly better
02:54 PM cehteh: use printf debugging asserts ir whatever then, blink an 'error' led on a gpio ,, anything that helps
03:00 PM soreau: vmt: I've had openocd working before and saved the .cfg file I used but it's throwing an error when I try now
03:02 PM soreau: I guess I have to flash it with the right bootloader
03:03 PM soreau: and I can't even do that.. huh
03:04 PM vmt: soreau: what are you using to flash the chip if not openocd?
03:04 PM soreau: vmt: arduino IDE
03:05 PM cehteh: :D
03:05 PM soreau: but the stflash utility used to work with stlink v2
03:05 PM soreau: let me try uploading via stlink from arduino IDE
03:06 PM soreau: nope
03:06 PM soreau: what the heck
03:06 PM soreau: well now I have other problems I guess
03:07 PM vmt: k
03:10 PM cehteh: lol
03:16 PM soreau: damn this sucks
03:16 PM soreau: I guess my stlink v2 is dead or something
03:16 PM cehteh: its not
03:16 PM cehteh: you connected it wrong or you usb stack crashed because of your earlier attempts to transfer audio
03:20 PM soreau: ah yes, jiggling the wires made it work again
03:21 PM soreau: that's not good
03:22 PM cehteh: soom some magic smoke will emerge
03:30 PM soreau: nah
03:30 PM soreau: I put new wires on it, seems to be happier now
03:34 PM soreau: I get "Remote replied unexpectedly to 'vMustReplyEmpty': timeout" from gdb after it sits for a few seconds
03:36 PM soreau: so that's a non-starter
03:41 PM soreau: it was wrong port
03:41 PM soreau: now I get "Truncated register 16 in remote 'g' packet"
03:41 PM soreau: and openocd says it's because the device needs reset
03:42 PM soreau: but with this bootloader the reset button doesn't do anything afaik
03:43 PM polprog: the reset button is not connected to the RESET# pin?
03:46 PM soreau: well with maple, it goes into dfu mode first with flashing led but when I upload using stlink method in arduino ide, this no longer happens
03:47 PM soreau: I haven't found a complete guide that tells step by step how this is intended to be used
03:48 PM soreau: everything on the web is very scattered
03:55 PM soreau: ok it helps if I actually run gdb-multiarch
03:55 PM soreau: now I set a breakpoint and continue but I get "WARNING! The target is already running. All changes GDB did to registers will be discarded! Waiting for target to halt."
03:55 PM soreau: and the device appears crashed with the flashing led
04:01 PM soreau: hey, my first bt
04:01 PM soreau: holy optimizations, batman
04:02 PM polprog: having fun with oocd?
04:02 PM polprog: what CPU?
04:04 PM soreau: polprog: it's a cortex m3 I think
04:04 PM soreau: whatever this bluepill stm32f103c8 has
04:04 PM polprog: stm32?
04:04 PM polprog: oh neat
04:04 PM polprog: bluepill
04:04 PM polprog: yeah, its a cortex m3
04:04 PM polprog: https://polprog.net/papiery/stm32/ help yourself
04:05 PM polprog: makefiles mostly for oocd scripting
04:05 PM soreau: oh thanks
04:05 PM soreau: Apache (Windows 95/98 4.10) heh
04:05 PM polprog: :^)
04:09 PM soreau: yea, this gdb is telling me what I already know
04:09 PM soreau: I need to know what I don't know
04:09 PM polprog: what do you need to know?
04:09 PM soreau: why the heck my isochronous transfers are only sending payloads on every other packet
04:10 PM soreau: regardless of double or single buffering
04:11 PM soreau: I copy it into PMA and set tx count but even though I get packets every frame, only half of them have payloads attached
04:12 PM soreau: and there's no copy-from-pma-to-host code I've found anywhere so I assume it's controlled by the hardware (registers?)
04:16 PM polprog: what packets
04:16 PM polprog: and what PMA?
04:16 PM polprog: ah usb
04:17 PM polprog: sorry, cant help. No idea
04:17 PM soreau: yea it's far out
05:13 PM nohit: this + HAL and you cant go wrong https://github.com/IntergatedCircuits/USBDevice
05:13 PM nohit: it even has this setup guide to setup it with CubeHAL https://github.com/IntergatedCircuits/USBDevice4Cube
05:14 PM soreau: thanks nohit
05:14 PM soreau: I'm working on filing the report
05:17 PM nohit: wait no wtf
05:17 PM nohit: there's no audio class
05:18 PM nohit: well, that's useless then
05:36 PM vmt: soreau: show some code
05:40 PM soreau: vmt: Here it comes
05:41 PM soreau: vmt: https://github.com/rogerclarkmelbourne/Arduino_STM32/issues/687
05:42 PM soreau: nohit: Your suggestion wasn't what you thought it was?
05:43 PM nohit: well it doeasnt have audio class, otherwise it would be fine
05:43 PM nohit: that's a shame
05:43 PM nohit: seems like something that's easy to setup
05:43 PM soreau: darn :/
05:47 PM vmt: soreau: tell openocd to reset and halt the device
05:48 PM soreau: anyway, I made the example to where anyone with an stm32f1(03c8) can run it without connecting anything
05:49 PM vmt: yeah that example is horrible to go through.
05:49 PM vmt: what exactly is your code and what is the library code
05:52 PM soreau: vmt: Just assume that entire patch is mine
05:52 PM soreau: vmt: The main function to look at is https://github.com/soreau/Arduino_STM32/commit/db300ca786b71bc5f6f0e7cfa75316d93c6c5f35#diff-2415201b08e9f075e95576436c33e23dR145
05:53 PM soreau: that's what is called each ms when the host makes an urb for the packet
05:53 PM soreau: I just hope apruss can help
11:56 PM day__ is now known as day