On Wed, Jun 8, 2016 at 4:10 PM, Marcin Kałuża <marcin.kaluza@xxxxxxxxxxxxxx> wrote: > Hello! > I'm looking for someone who was able to successfully use Octopus Dual > CI bridge by Digital Devices under Linux. We got it _almost_ working - > we have a strange problem of the module dropping TS packets in sets of > 30-33 packets rather randomly and this corrupts the whole stream. > > Their support ignored the ticket so far > (http://support.digital-devices.eu/ticket.php?track=UG1-B42-NSGV&e=marcin.kaluza%40trioptimum.com&Refresh=51010) > and we're slowly running out of options. > > We've tried rebuilding the module using streaming dma api > (DDB_ALT_DMA), we changed the kernel (our 3.18.22 and 4.2.3 from FC > 23), disabled smp, still the same. > > Strange things happen when I call read() to get data back from CI, if > I use any other buffer size then their internal dma buffer (672*188), > I sometimes get the data not in order I wrote them (we use test TS > stream with a counter inside ts payload), and the strangest of all - > if I use bigger buffer (i.e. 1000*188), read() always returns that > value (188000), but actual amount of content in my read buffer vary > greatly (although never exeeds their buffer size of 672*188) - we > clear the read buffer before each read so we know how much data was > actually read. That's probably a bug, but I have no idea how can this > even happen (their code > (https://github.com/DigitalDevices/dddvb/blob/master/ddbridge/ddbridge-core.c#L772) > looks quite ok as for my not so great knowledge of linux kernel driver > coding). Has anyone encountered similar problems? It looks like a race > condition of some sort, but I was unable find/fix it. > > I'll be most grateful for any reply/suggestions/help... > Martin This mailing list generally isn't for vendors' out-of-kernel drivers. If Digital Devices wants to not be responsive to users who bought their products and wants the community to provide free tech support for their devices, they should get their drivers merged upstream. :-) That said, the math in ddb_input_read() looks pretty wonky. The fact that it always returns count (i.e. the size of the buffer provided from userland), without taking into account how much data is actually in the ring buffer certainly looks wrong. If there isn't enough data available, it should return the amount of data that *is* available, not the size of the buffer passed in from userland. I would add some more logging to that routine and see what's going on. You'll probably have to take some time to understand what the actual buffer filling algorithm is supposed to be for that hardware in order to figure out what's going wrong. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
