[alsa-devel] Correct use of ak4114.c?

[dustin at seznam.cz]

Perhaps a solution could involve splitting ak4114 support into spdif-in and spdif-out. When creating ak4114 we could specify which part should be active. Default would be both parts in order to keep existing funcionality. The change would only concern controls definition and corresponding snd_ctl_notify calls anyway.

Thanks.

Pavel.


>  ------------ Původní zpráva ------------
>  Od:  <dustin at seznam.cz>
>  Předmět: Re: [alsa-devel] Correct use of ak4114.c?
>  Datum: 01.4.2007 23:09:13
>  ----------------------------------------
>  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.
>  
>  
>  >  > 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.
>  
>  Best regards, 
>  
>  Pavel.
>  _______________________________________________
>  Alsa-devel mailing list
>  Alsa-devel at alsa-project.org
>  http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
>  
>  
>