ralphy wrote: > Because when I copied the classicfm.aac file to my test system ... Ha ! An 'other factor'. I might not have owned up to that. :)
ralphy wrote: > > I've rerun the test and can confirm that I get 37 sync errors but the > file plays...with a few "blips" in the audio. > There are 41 icy-metadata chunks in the file. So that might make sense. I was surprised that the stock firmware only reported one sync error, and appeared to play without blips. Perhaps the stock firmware is just "better" at gliding over corrupted incoming data and avoiding the problem in the first place. ralphy wrote: > > I also get concealing corrupted frames messages, which the stock > firmware doesn't report or appear to have similiar. > This is beyond my knowledge level. I see no more than you. I used to have an object dump (from -readelf-, I think) of the symbols, but I threw it away. A session with -ghidra- might reveal more if you really wanted to know, but the thought does not really fill me with enthusiasm, and it is, perhaps, of academic interest only. ralphy wrote: > > It's great to be able to confirm that the sync error code handles > works. > I think you can be very pleased with the result. I guess the decoder element is just seeing a lot more of the errors than it would in the 'stock' firmware. Chasing that down seems to me to be a real labour of love. Given that all incoming stream data is somewhat protected by way of being delivered by TCP, and can reasonably be assumed to come from a competent server, I think that you may have done enough. Unless another hiccup should arrive out of the blue .... :) ------------------------------------------------------------------------ mrw's Profile: http://forums.slimdevices.com/member.php?userid=38299 View this thread: http://forums.slimdevices.com/showthread.php?t=113719 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
