You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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_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.The text was updated successfully, but these errors were encountered: