At Sun, 01 Apr 2007 23:09:01 +0200 (CEST),
dustin@xxxxxxxxx wrote:
>
> Hi Takashi
> >
> > > BTW, what is difference between professional and spdif pcms? Is it
> > > only about digital format (like professional/consumer in iecset)?
> > > Sorry for stupid questions, but I do not know which pcm to use.
> >
> > VT1724 has seperate DMAs for the analog and the SPDIF streams while
> > ICE1712 has only one for both (mixed up).
> >
> > Confusingly the analog PCM is named "professional" there because it
> > was called so in ice1712 driver, and vt1724 driver is derived from
> > ice1712 driver. ICE1712 has two analog connections modes, consumer
> > mode (usually via ac97) and professional mode (via i2s).
> >
>
>
> Uff, that is a lot of background knowledge. Would it be possible to
> put this explanation into ice1724.c code? It would definitely help
> newcomers. Thanks a lot.
A patch is welcome ;)
> > > Would I get to playback/capture substreams e.g. using
> > > ice->pcm_pro->streams[0/1]->substream at the end of
> > > snd_vt1724_probe? I understand I could probably find this
> > > information in alsa documentation.
> >
> > The build_controls callback is called after creation of PCMs.
> > So, you can call it there. The proposed fix for Juli is below.
> >
> > Can any Juli users test the latest HG version with this patch?
> >
>
> I tested the code with prodigy192 and my current ak4114 code. I used
> ice->pcm stream instead of ice->pcm_pro
> since I guess that is the one for SPDIF data.
>
> Probing the module produced error -16 (EBUSY). Analysis showed
> duplicity of control item
> SNDRV_CTL_NAME_IEC958("",PLAYBACK,DEFAULT) defined in ice1724.c
> (snd_vt1724_spdif_default) as well as ak4114.c . Upon removing the
> control from ak4114.c (and adjusting AK4114_CONTROLS) the module
> loaded correctly and all the new PCM controls were available in
> amixer.
>
> I think the problem is that the ak4114 support assumes both SPDIF
> OUT and IN functions are used, whereas ice1724 support assumes
> SPDIF-OUT is handled by ice1724, leaving only SPDIF-IN to other
> chips. At least with Prodigy192 + MI/ODI/O that is the case in
> reality too (ak4114 spdif-out capability is not used, signal goes
> from ice1724 directly to output buffers on the add-on card).
>
> What solution would you suggest? I guess a solution would be to
> check for duplicity before adding new controls, or perhaps continue
> after hitting error EBUSY in snd_ctl_add.
Then the problem is that it passed the playback substream to
snd_ak4114_build(). I guess passing NULL there instead should work.
Takashi
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
