I'm trying to optimize the transmission of PAD data: my goal is to stay in the 6 bytes, because sound quality is more important to me than logo visualization speed, but I'd still like to give users a nice experience.
So far I've reached a nice situation by using a small logo, that can be transmitted in about 90 seconds. I've seen that, with such a low bandwidth, even the frequency of the DLS transmission (label_insertion) has a great impact. I tried setting it to 5, or 10 seconds, and the slide transmission time decreases significantly.
I can accept the fact that the user will need to wait a few seconds before he sees the current title, but I'd prefer to update it in nearly real time when the song changes, so I'm writing a .REQUEST_DLS_REREAD file every time the song changes, and it works like a charm, except for a weird behavior.
Sometimes (more frequently than I would estimate, actually) my title update comes while a DLS is already transmitting, so I see the ODR-PadEnc Warning: skipping label insertion, as previous one still in transmission! warning message, which is totally fine. However, this delays the new title trasmission for the entire label_insertion time, and this is something that I wouldn't expect. Instead, I'd expect that, if this happens, the new label is transmitted just after the previous one ended transmission. I made a change for this and I'm testing it since a few weeks: it seems to run as I expect.
It should probably be the same logic for slides, but this is more borderline as an error in setting --sleep would result in an endless transmission loop, as if the parameter was set to 0. But for small payloads like the DLS, I think it makes sense.
I'm trying to optimize the transmission of PAD data: my goal is to stay in the 6 bytes, because sound quality is more important to me than logo visualization speed, but I'd still like to give users a nice experience.
So far I've reached a nice situation by using a small logo, that can be transmitted in about 90 seconds. I've seen that, with such a low bandwidth, even the frequency of the DLS transmission (
label_insertion) has a great impact. I tried setting it to 5, or 10 seconds, and the slide transmission time decreases significantly.I can accept the fact that the user will need to wait a few seconds before he sees the current title, but I'd prefer to update it in nearly real time when the song changes, so I'm writing a .REQUEST_DLS_REREAD file every time the song changes, and it works like a charm, except for a weird behavior.
Sometimes (more frequently than I would estimate, actually) my title update comes while a DLS is already transmitting, so I see the
ODR-PadEnc Warning: skipping label insertion, as previous one still in transmission!warning message, which is totally fine. However, this delays the new title trasmission for the entirelabel_insertiontime, and this is something that I wouldn't expect. Instead, I'd expect that, if this happens, the new label is transmitted just after the previous one ended transmission. I made a change for this and I'm testing it since a few weeks: it seems to run as I expect.It should probably be the same logic for slides, but this is more borderline as an error in setting
--sleepwould result in an endless transmission loop, as if the parameter was set to 0. But for small payloads like the DLS, I think it makes sense.