Menu
▾
▴
#29 ES_OUT_SET_(GROUP_)PCR is called too late
I am using cdemu 3.2.4 - (C) 2006-2020 Rok Mandeljc
This seems to work fine when using it by itself, even when I use a media player such as vlc on it (cdda).
However, if I start using my actual cdrom device simultaniously with my emulated cdrom (such as just reading), the emulated cd becomes very choppy and it lags. It feels like the emulated cdrom is tied into the hardware some way, or there is something that is causing conflict..
Any idea how to give cdemu enough processing to not lag like this?
At first I thought this might be because of little or no buffering in the player, but from what you are describing it sounds more likely that your physical CD/DVD-ROM somehow is running with DMA disabled, this will cause a lot of unnecessary load on your CPU. It's not normal for i/o to another disc to affect playback on another drive.
The tricky part I guess would be to find out if this is the case. If your drive is an ATA/ATAPI drive you can try:
hdparm -acd /dev/XXX
where XXX is your physical device. In case of SATA drive you could try:
dmesg | grep -i scsi
and look for a possibly missing "Direct-Access ATA" message. Apparently the presence of this message should indicate that DMA is enabled.
I'm not sure how to check if a SCSI device has DMA enabled, but I suspect it can be checked in a similar fashion.
If you wish you can also check VLC Tools - Preferences - All - Input / Codecs - Disc caching (ms). On my computer it was set to 300, I would recommend 1000 ms as a reasonable default, but you could experiment by setting it a little higher to compensate for high CPU load. This is not a proper fix though. A proper fix would be enabling DMA on the drive which will in turn significantly reduce i/o overhead.
So please report back if you have any luck checking if DMA is enabled or not.
I found that if I ran on a RT kernel that I didn't see this behavior at all, or at the very least it deminished it.