Curator of Mastodon.art fediblock :newt: (npub1wc2…4sk7)
That's an insane amount of bullshit here, sir!
Had it been the case DMA would have never existed in the first place. It might take certain effort to manage the buffer — and it does anyway, independently on the way you transmit the data, some buffer is always present, at least to keep a certain number of full samples.
But it's not rocket surgery, I think some sort of ring buffer is used. Or maybe two buffers are used — when the device is finished reading one of them, it issues an interrupt and CPU can start filling it again while the device is working with the other one, they keep being switched until the playback is finished. It sure doesn't have to be infinite.
Details of implementation aren't really important, what is — that writing to local memory and just notifying the device that new data is present so the device can read it independently of CPU is a way cheaper operation than pushing ALL THE DATA through the bus using that same CPU.
Some feedback from the device is present in both cases: there could be a buffer underrun or the opposite — the device might be overwhelmed with data and you have to stop transmitting it, it's not like you can shoot all data down the USB bus as fast as you can. It's just that the way to put new data into it is a matter of writing to local memory with DMA — a very cheap operation, compared to… anything really.
✙ dcc :pedomustdie: :phear_slackware: (npub1lar…q5vr) kaia (npub1c4s…aqv4) Eric Zhang 2: Episode 1 (npub1eeu…ap7h)
m0xEE /
npub1y7…zgta6
2024-03-12 20:57:50
in reply to nevent1q…8wn3
Author Public Key
npub1y749ew2wfqfydazhmy9xj0qegvfkn8qlrm3grc8x2u3lplcxufds6zgta6Published at
2024-03-12 20:57:50Event JSON
{
"id": "8bd6ecda436bcb12b157775eb0b7d7352cf68b5251e42c76583ada799a8f82c5",
"pubkey": "27aa5cb94e481246f457d90a693c194313699c1f1ee281e0e65723f0ff06e25b",
"created_at": 1710273470,
"kind": 1,
"tags": [
[
"p",
"7615614e4ed5bed70847ce5a32852a79ddde9dce8a650059f31546d61c1ad441",
"wss://relay.mostr.pub"
],
[
"p",
"ff479c63a264a52994dec047cff0c7fdff88ccba2ffb152705d7dba3e31266bc",
"wss://relay.mostr.pub"
],
[
"p",
"c56086c6ba87cbcbfb72bcca534a1cf2ced76e95b7f57306367809fad85a616a",
"wss://relay.mostr.pub"
],
[
"p",
"ce796670981cbb29421826bbbc60d2cbe1643c4ffea6e9849b1682405bba2e41",
"wss://relay.mostr.pub"
],
[
"e",
"a11d9d3a5e59be77e16816383f223c58514ed96ad53b8161743cdc4af8e854e1",
"wss://relay.mostr.pub",
"reply"
],
[
"proxy",
"https://breloma.m0xee.net/objects/68f934ac-feb9-40b2-b2eb-e73296d127aa",
"activitypub"
]
],
"content": "nostr:npub1wc2kznjw6kldwzz8eedr9pf208waa8ww3fjsqk0nz4rdv8q663qswt4sk7 \nThat's an insane amount of bullshit here, sir!\nHad it been the case DMA would have never existed in the first place. It might take certain effort to manage the buffer — and it does anyway, independently on the way you transmit the data, some buffer is always present, at least to keep a certain number of full samples.\nBut it's not rocket surgery, I think some sort of ring buffer is used. Or maybe two buffers are used — when the device is finished reading one of them, it issues an interrupt and CPU can start filling it again while the device is working with the other one, they keep being switched until the playback is finished. It sure doesn't have to be infinite.\nDetails of implementation aren't really important, what is — that writing to local memory and just notifying the device that new data is present so the device can read it independently of CPU is a way cheaper operation than pushing ALL THE DATA through the bus using that same CPU.\nSome feedback from the device is present in both cases: there could be a buffer underrun or the opposite — the device might be overwhelmed with data and you have to stop transmitting it, it's not like you can shoot all data down the USB bus as fast as you can. It's just that the way to put new data into it is a matter of writing to local memory with DMA — a very cheap operation, compared to… anything really.\nnostr:npub1lareccazvjjjn9x7cprulux8lhlc3n969la32fc96ld68ccjv67qguq5vr nostr:npub1c4sgd346sl9uh7mjhn99xjsu7t8dwm54kl6hxp3k0qyl4kz6v94qh5aqv4 nostr:npub1eeukvuycrjajjsscy6amccxje0skg0z0l6nwnpymz6pyqka69eqs88ap7h",
"sig": "9aed703f9add6125f00b89dcf920209802b1b8a9b1ea9ddba8a66a943eab4ab37cb9bc605bfe763051d0af37b3231e52a0a285d6d3609d2c96b095ae33ddc4fc"
}