On 10/25/2011 14:54, Jeremy Chadwick wrote:
On Tue, Oct 25, 2011 at 01:18:47PM +0200, Claude Buisson wrote:
On 10/25/2011 12:52, Daniel O'Connor wrote:
On 25/10/2011, at 20:45, Claude Buisson wrote:
When upgrading a system to 8.2-STABLE, I switched my kernel from atapicam to
ATA_CAM, and found that vlc could not play audio CDs anymore. Reverting to
atapicam (and reverting from cdN to acdN of course), vlc was OK again.
It seems that I am not the only one having this kind of problem, as I found (for
example) this message on questions@ (for releng9):
http://lists.freebsd.org/pipermail/freebsd-questions/2011-October/234737.html
Is this a known problem ? Is somebody working on it ?
Have you tried pointing VLC at /dev/cd0 when using ATA_CAM?
Of course yes ! (I even configured WITH_CDROM_DEVICE=/dev/cd1 when building VLC)
It may be trying old style ATA ioctls based on the device name.
VLC recognize the tracks and jump quickly from one to the following, without
playing it, and with a flow of messages:
[0x2caf2a3c] cdda access error: Could not set block size
[0x2caf2a3c] cdda access error: cannot read sector nnnnn
where the sector number is incremented, and then emit (2 times if I remenber):
[0x2af28bc] es demux error: cannot peek
Sorry for having ommited these messages in the previous mail.
I found a PR 161760 about cdparanoia needing to be patched for 9.0 with CAM, a
proposal by avg@ related to libxine:
http://lists.freebsd.org/pipermail/freebsd-multimedia/2010-December/011414.html
These may not be the same problem, but I think they are related (a not so well
documented change in the kerm interface).
You want atapicam(4). This is not the same thing as "options ATA_CAM".
See /sys/conf/NOTES.
Whether or not it works with audio CDs is unknown to me.
I *know* the difference between atapicam and ATA_CAM ;-)
I have done other tests on 8.X and 7.X, and found that audio CDs cannot be
played with atapicam.
BUT, I understood (wrongly ?) that ATA_CAM was the way to go starting with 9.X,
which imply that the traditionnal acdN interface will disappear.
A valid answer to my question may be: "we - kernel developpers - know about it,
but we don't care, and the problem must be solved by the userland/applications
developpers".
With some obvious consequences on the upgrading or not upgrading of end users
systems.
Claude Buisson
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
