I'd be interested in seeing schematics please.ceteras wrote:I believe the drivers question is more important.
his is an 8-pin chip, I2S, easy to use. A dual opamp would be needed to convert its current output into voltage. I'll post schematics if anybody wants to try.
That's a good find, I think it would work great with the PCM module in master mode.Sight Unseen wrote:What about this chip? It has an onboard PLL to generate MCLK, and only requires the 3-wire I2S itself:
That is the PCM/I2S clock you just enabled. It controls the speed at which the PCM/I2S runs, provided you select the 'internal clock' mode"> PCM_CLK: seems to be the clock at which the I2S system is actually running (can be either PCM_MCLK or fed via GPIO18 from the outside).
Is it possible for testdebug0 and testdebug1 to be accessible test points on the pcb, so we can provide our own specially designed master clock source? If these test points are not used for something else in operation, that would be great!DogEars wrote: (03 Jul 2012 06:51)
Assuming the sources for the PCM clock are the same as the general purpose clocks?
0 = GND
1 = oscillator
2 = testdebug0
3 = testdebug1
4 = PLLA per
5 = PLLC per
6 = PLLD per
7 = HDMI auxiliary
8-15 = GND
We've got it working with the bit clock (PCM_CLK) running at 1.4112MHz (44.1KHz@16bit) using the dividers register mentioned earlier in this thread by Gert to get the correct result.ceteras wrote: PCM_CLK is 2.8224 MHz for 44.1kHz sample frequency for instance, clearly cannot be the 19.2MHz crystal source enabled by "(Clock source code = 0001b) ".
I'm a software developer, but nothing at this level, this is just out of curiosity. We're hoping to create an open audio platform with the rpi being the brain at the centre, effort hasn't really started due to other family commitments but things are due to change next week.trackstand wrote:Piece of cake, surely?
Dogears, I gather this is 'work' for you - is the outcome going to be some commercial product?
Ah, I mistook your original question for irony. I'm afraid I'm in the same boat as you - software developer but I've never done a driver and so also have no idea what is involved. Strikes me that it falls under ALSA. Forgive me if you've already been down this road but a quick google found:DogEars wrote: So on that note, I'll reiterate my original question, how hard can it be, what is involved?
Takashi Iwai has written "Writing an ALSA Driver" - a very comprehensive guide to developing a device driver for ALSA.
The document focuses mainly on the PCI soundcard. In the case of other device types, the API might be different. However the ALSA kernel API is consistent so it will be helpful in that context.
Gert, can you tell me which other clock sources are available in the CONTROL register of I2S?Gert van Loo wrote: CONTROL @ 0x7E101098
Enable bit = 4
Clock source is bits 3:0.
I assume you want the cleanest clock source which is the XTAL
(19.2MHz) crystal. (Clock source code = 0001b)
Where I can find more information about this clocks? I would like to configure the clock with half of the frequency Dariush has doneGert van Loo wrote:You probably need to enable the clock to the I2S module.
All clocks, power and reset are in a separate section.
There is an omission in the datasheet in that it does not mention those.
Do NOT experiment with trying to guess registers in that area.
Especially if you start 'playing' with, or accidentally hit a power register
you have the small, but distinct possibility of blowing up your PI.
I will see what I can find, but it will take a while as I do not have the
full datasheets here at home.
Is there any progress on this? If the I2S of the RPI can output BMC http://en.wikipedia.org/wiki/Biphase_mark_code then with the epanorama schematic it shoud be possible...N2TOH wrote:not to arm chair engineer things here, but you folks might want to take a look at this site with S/PDIF and TOSLINK interfaces. http://www.epanorama.net/documents/audio/spdif.html from what I gather it should be very cheap to add on a set of SPDIF inputs and outputs for the Pi.