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
Hi,
Although I've encountered some issues with the DY-SV5W player, I am not here to report any issues specifically related to your software. I hope that I may just share a few quirks/observations with you and I certainly welcome your feedback. I see that you have written a very nice library and in the process have learned much about the quirks of these devices.
I have written my own library for a project I'm working on. Briefly, one aspect of my project is that it has several toggle switches, each which plays a pre-determined sound file. When flipping a switch while an existing sound file is playing, it seems that I can't just send a "stop play", followed by the command to start a new track without the board getting "confused" and out of sync. What I discovered I had to do is first issue the "stop play", then wait for the "busy" signal input to change state to "not busy". Only then can I start the new track and all is well. I have implemented a state machine to handle this. Why? Well there is another nuance. After you start a new track, "busy" isn't immediately asserted and you have to wait for "busy" to assert which takes some time (typically 500ms or more). Then if you want to end the track, then once "busy" is asserted, you can then send "stop", then wait for "not busy" and then start a new track. When switching rapidly, there is a chance that we started the track and it is not yet busy even though we want to change to a different track. My system will wait for it to become busy before sending the stop play command, then send the stop playing command, and then wait for it to be "not busy". So tracks don't switch instantly, but fast enough, in essence it can be thought of as a "debounce" when the state changes. All is done in a very deliberate and controlled fashion which seems to solve the sync problems and allow it to work consistently and reliably. I hope that makes sense. I'm curious if you've encountered this behavior.
Also, I recently added the ability to use folders. So now, when I start a track, I use the path command and always use the syntax /AFOLDER*/00001*MP3. The documentation indicates that the folder name length is limited to 8 characters, but it seems it is limited to 7 characters not 8 (7 works, 8 doesn't as per my tests). I wonder if it is limited to 7 because the * is counted, so "AFOLDER*" is considered to be 8 characters. Thoughts?
At any rate, I would enjoy hearing any feedback you might have on these two issues/concerns.
Thanks!
Greg
The text was updated successfully, but these errors were encountered:
I encountered the same issue with the lag before the BUSY signal. I could understand why there would be a slight delay, but it seems strange that it is quite so long! I've used two possible solutions to ensure the audio has stopped - the first is to check both that the busy line is HIGH and also that >1000ms has elapsed since the last play command was sent, and the other is, after issugin a play command, keep track of a HIGH-LOW-HIGH transition on the busy line, rather than just testing whether it is HIGH.
Hi,
Although I've encountered some issues with the DY-SV5W player, I am not here to report any issues specifically related to your software. I hope that I may just share a few quirks/observations with you and I certainly welcome your feedback. I see that you have written a very nice library and in the process have learned much about the quirks of these devices.
I have written my own library for a project I'm working on. Briefly, one aspect of my project is that it has several toggle switches, each which plays a pre-determined sound file. When flipping a switch while an existing sound file is playing, it seems that I can't just send a "stop play", followed by the command to start a new track without the board getting "confused" and out of sync. What I discovered I had to do is first issue the "stop play", then wait for the "busy" signal input to change state to "not busy". Only then can I start the new track and all is well. I have implemented a state machine to handle this. Why? Well there is another nuance. After you start a new track, "busy" isn't immediately asserted and you have to wait for "busy" to assert which takes some time (typically 500ms or more). Then if you want to end the track, then once "busy" is asserted, you can then send "stop", then wait for "not busy" and then start a new track. When switching rapidly, there is a chance that we started the track and it is not yet busy even though we want to change to a different track. My system will wait for it to become busy before sending the stop play command, then send the stop playing command, and then wait for it to be "not busy". So tracks don't switch instantly, but fast enough, in essence it can be thought of as a "debounce" when the state changes. All is done in a very deliberate and controlled fashion which seems to solve the sync problems and allow it to work consistently and reliably. I hope that makes sense. I'm curious if you've encountered this behavior.
Also, I recently added the ability to use folders. So now, when I start a track, I use the path command and always use the syntax
/AFOLDER*/00001*MP3
. The documentation indicates that the folder name length is limited to 8 characters, but it seems it is limited to 7 characters not 8 (7 works, 8 doesn't as per my tests). I wonder if it is limited to 7 because the*
is counted, so "AFOLDER*" is considered to be 8 characters. Thoughts?At any rate, I would enjoy hearing any feedback you might have on these two issues/concerns.
Thanks!
Greg
The text was updated successfully, but these errors were encountered: