From owner-freebsd-arch@FreeBSD.ORG Thu Dec 2 15:42:24 2010 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B227D10656A8 for ; Thu, 2 Dec 2010 15:42:24 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 099DF8FC1E for ; Thu, 2 Dec 2010 15:42:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id RAA07786 for ; Thu, 02 Dec 2010 17:23:15 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CF7B9E2.40106@freebsd.org> Date: Thu, 02 Dec 2010 17:23:14 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-arch@freebsd.org X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: accessing data on audio cd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2010 15:42:24 -0000 This is a pretty minor issue in the grand scheme of things, but still seems to be an architectural one. Currently we do not have a uniform way between cd(4) and acd(4) to extract data from Audio CDs. There are shared ioctls to query table of contents, start analog playback of a given track and whatnot. But no common way to digitally extract the audio data. acd(4) allows read(2) with block size of 2352 bytes. With cd(4) the only was is to use pass(4). I see a few options: 1. do nothing 1a. use of audio CDs on PCs is going to go away eventually; 1b. acd(4) is going to be replaced by cd(4) eventually, via ahci, ATA_CAM, atapicam, etc; 1c. userland programs should take care of the differences or use some form of pass-through interface and use only MMC command; 2. add support for 2352-reading to cd(4); 3. add a new shared ioctl to read a given 2352-byte block of an audio CD. I am personally torn between #1 and #3. #2 is not bad, but it's an extra complexity. The reason I am raising this issue at all is a result of my frustration with some userland libraries/programs. Some libraries handle both cd and acd but have quite a bit of duplicate code, others (correctly) handle only one of the interfaces. What do you think? Thanks! -- Andriy Gapon