Https clicktime symantec com driver#
Https clicktime symantec com code#

*lt += pPvtData->packetsSinceAvtpAlignment * pPvtData->txIntervalNs If (pMediaQItem->readIdx = 0) /* packet and frame align at AVTP time */ PMediaQItem = openavbMediaQTailLock(pMediaQ, true) Pvt_data_t *pPvtData = pMediaQ->pPvtMapInfo I have simplified it to the following in my branch:īool openavbMapUncmpLaunchtimeCalculationCB(media_q_t *pMediaQ, U64 *lt) The offset be maxTransitUsec rather than a fixed one It subtract an offset from the AVTP presentation time to determine the TX timestamp, rather than adding one? The logic in openavbMapUncmpLaunchtimCalculationCB() confuses me – shouldn’t: I’ve made some modifications to ptp4l to support the shared memory interface exported by the Intel gPTP daemon (so it can replace it), as well as supporting both transports on a single NIC. > It does require a PTP boundary clock that supports both PTPv2 over UDP and 802.1AS. It’s not working reliably yet (difficult to debug timestamps that roll over quickly, particularly with proprietary endpoints). > The idea is to shuffle packets for one protocol domain to the other, adjusting for capture vs presentation time on the way. > Not sure if this is project is still alive, but I’ve started hacking on an AES67 to AVB bridge. > On, at 7:36 pm, Luke Howard via Open-avb-devel > wrote: > *lt -= pPvtData->maxTransitUsec * NANOSECONDS_PER_USEC

> * Adjust the AVTP presentation time back to the ingress time using > *lt += pPvtData->packetsSinceAvtpAlignment * pPvtData->txIntervalNs > *lt = pMediaQItem->pAvtpTime->timeNsec > pPvtData->packetsSinceAvtpAlignment = 0 > if (pMediaQItem->readIdx = 0) /* packet and frame align at AVTP time */ > pMediaQItem = openavbMediaQTailLock(pMediaQ, true)

> pvt_data_t *pPvtData = pMediaQ->pPvtMapInfo > bool openavbMapUncmpLaunchtimeCalculationCB(media_q_t *pMediaQ, U64 *lt) > I have simplified it to the following in my branch: > the offset be maxTransitUsec rather than a fixed one > It subtract an offset from the AVTP presentation time to determine the TX timestamp, rather than adding one? > The logic in openavbMapUncmpLaunchtimCalculationCB() confuses me – shouldn’t: > On, at 5:02 pm, Luke Howard via Open-avb-devel wrote:

Https clicktime symantec com code#

Not doing this confused the endpoint I was testing against.įor those playing along at home, the code below was bogus – at least, it’s not necessary to adjust by the transit time as openavbMapUncmpLaunchtimeCalculationCB() is called before the mapper function and thus before the transit time has been added to the AVTP timestamp. While (framesProcessed < framesPerPacket)ĪvtpTime := getAvtpTimestamp(mediaQItem) + ((framesAlreadySent + framesProcessed) / audioRate) * NS frames sent thus far in media queue itemįramesAlreadySent := readIdx / itemFrameSizeBytes Shouldn’t the media queue timestamp only be used with a fresh media queue item, and then advance by the duration of the frames written out thus far? e.g. It appears that AVTP timestamps are always set to the presentation time of the first item in the media queue. being able to keep media queue items in network byte order), but I did have one question about the 61883-6 mapper. Most of the issues I ran into were trivial or feature requests (e.g. I collected some notes on this very rough WIP here: Stefan Asenkerschbaumer Geschäftsführung: Dr. Robert Bosch GmbH | Postfach | 31132 Hildesheim | GERMANY | Tel.

Https clicktime symantec com driver#

I am using basically the driver from the kernel 5.17 and I have added the necessary API functions in order to support AVB.Ĭross-Domain Computing Solutions, Engineering Daimler (XC-CT/EDA1.2) I tried also the alsa plugin for AVB, but the max uncertainty MTU is not met using alsa plugin with 'SO_TIMESTAMP' usage. The application in the user space is allocating the DAM buffer.Īfter the mmap function is successfuly finished the next call is memset(0) to the dma memory buffer. 'static int igb_mmap(struct file *file, struct vm_area_struct *vma)'. The function 'remap_pfn_range' is called, in the function: In my observation the virtual address has 8 bytes length in kernel 5.17 and 12 bytes length in kernel 5.18. The exact same source code does not work with kernel 5.18 any more.ĭo you know, if there is a change in regard to the mmap function between kernel 5.17 and 5.18? The driver using mmap works until the linux kernel 5.17.Īt least at my setup, using Fedora 64 with the kernel 5.17. It is not maintained any more, but maybe you can tell me, why the DMA function 'remap_pfn_range' does not work any more.

Topic: IGB AVB driver and kernel 5.18, DMA access