ripping by i2S

The question is not clear. - I2S is suitable for audio transfer and distribution in who knows how many millions of consumer electronic devices, so ...

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

I think the OP want to re-create a CD by way of the output I2S audio channel.

The timing of the I2S:

Does this sound about right ?

hamilton

Let me rephrase - Why would a protocol that is,

(a) designed to transport audio data. (b) adopted in mass by the CE industry. (c) supported in mass by component manufacturers. (d) incorporated into other successful standards, (HDMI)

not be suitable to do what it is designed to do and is successfully doing all around us?

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

I am sorry Roberto, the question was for dkotrappa.

dkotrappa, it your goal to re-create a CD from the I2S output ??

hamilton

Are you sure you are not mixing up with SPD/IF ??

Risto

Sorry, thanks for the correction, ignore (d) The project I'm currently working on recovers the external SPDIF signal from HDMI as I2S for "inside the box", and I mixed them up.

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

Hello All, thanks for your replies, let me know rephrase my question.

question: Our Older board used ATAPI bus connected to CD-drive, the ripping was achieved by applications/middleware above ATAPI driver by ATAPI commands like

read TOC, CD-READ. But our newer board now connects CD-Drive via I2S bus (real time quadrapole sound bus),Is it possible to achieve ripping function by upper applications with I2S interface to CD-drive?

The a small hardware modification suggested by vendor is as follows +---------------+

+------+L/R clk | | +----------+ | DVD | ----------------+---+-----+ +----+----+ | | |video | SPACE(I2S SYNC) | FF | |AND |------|L/R CLK | |maker | --------------------+-----+----+-----+----+ | (naviCPU)| | | BIT CLK +-----------------|SPACE | | |--------------------------------------------------|BIT-CLK | | | DATA | | | |--------------------------------------------------|DATA | +------+ +----------+ Note: FF - flip flop, AND - and gate 1.In Navi CPU, recognize change in SPACE signal, and determine that it is start of recording.

1. recognize change in L/R-CLK signal and start fetching data to be recorded.

My question is does I2S driver require this kind of hardware change to achieve ripping by applications?

--------------------------------------- Posted through

Well - Now what you want to do is more clear, but I am afraid the only answer we can give you is, "maybe"

Since you mention "ATAPI driver" and "upper applications" I assume you are using an OS, as opposed to running a dedicated program on bare hardware.

What OS? What processor? What drivers? (Vendor provided, written in-house, downloaded from somewhere? With or without sources? Documented or normal?)

You need to look at two different levels: (a) HW interface and low-level drivers. Can you control the device, can you read audio data from it?

(b) Application/OS interface. Do you have an API to access that data from the OS.? Is that API compatible with the older system?

And again, too much information is missing to give meaningful pointers.

-- Roberto Waltman

[ Please reply to the group, return address is invalid ]

quadrapole

applications

is

Yes, we are using t-kernel OS.

processor is ARM, I2S driver is written in-house, and documented. The upper application in case of ATAPI driver, used ATAPI commands read TOC, read CD to read audio data as a file. In case of I2S driver, such ATAPI commands can not be issued. As I digged thru I2S driver source, I2S driver provides internal buffer to store audio data and it gives external interface to instruct driver start recording, stop recording, and read recorded data into external buffer maintained by upper applications, Is such interfaces enough for upper applications to perform ripping?

--------------------------------------- Posted through

The I2S bus only handles the audio data - the modification suggested by your drive supplier might work to get the audio data through but you will still need another interface for the processor to control the normal drive functions. I expect that there is either an additional interface bus to the drive or there is a possibility that it uses some modification of I2S (unlikely). How many physical connections are there on the drive ?

Michael Kellett

Note that unless you can command the drive to play back audio at several times the normal rate, the user experience will be pretty sucky.

-a

Precisely - You may still be able to use the previous ATAPI commands, with or without the I2S link.

-- Roberto Waltman

[ Please reply to the group. Return address is invalid ]

commands

+----------+

|

|

(naviCPU)|

|

| |

|

+----------+

it

to

I2S

external

Only one i.e I2S. Do I conclude that with only I2S ripping may not be possible?

--------------------------------------- Posted through

For this, Do we need any additional ATAPI interface along with I2S interface?

As I mentioned earlier, ATAPI is completely replaced with I2S.

--------------------------------------- Posted through

I am new to I2S, please help me understand how this works.

The I2S spec:

The ATAPI spec is:

Please explain the differences.

Thank you,

hamilton

If the only electronic interface is I2S then I assume the the basic control functions like track select and play/stop etc are manual and integrated into the drive along with the necessary clock recovery and buffering stuff needed to make I2S work. If this is the case you could still extract the audio data and process it but you won't have any way of selecting or identifying tracks via I2S unless some non standard capabilities have been added. Do you have a manual for this drive (or a part number).

Michael Kellett