From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: How to put 16bit none audio PCM data stream into a 32bit none audio S/P-DIF transport stream? Date: Wed, 09 Apr 2003 15:11:49 +0200 Sender: alsa-devel-admin@lists.sourceforge.net Message-ID: References: <20030408140230.GA1987@ulima.unil.ch> <3E934193.6090605@cucumelo.org> <20030408205515.GB6940@ulima.unil.ch> <3E933EF6.5030601@superbug.demon.co.uk> <3E93C4CA.4080604@cucumelo.org> <20030409082815.GA14489@ulima.unil.ch> <20030409114312.GE14489@ulima.unil.ch> Mime-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi") Content-Type: multipart/mixed; boundary="Multipart_Wed_Apr__9_15:11:49_2003-1" Return-path: In-Reply-To: <20030409114312.GE14489@ulima.unil.ch> Errors-To: alsa-devel-admin@lists.sourceforge.net List-Help: List-Post: List-Subscribe: , List-Unsubscribe: , List-Archive: To: Gregoire Favre Cc: Benny Sjostrand , James Courtier-Dutton , alsa-devel@lists.sourceforge.net List-Id: alsa-devel@alsa-project.org --Multipart_Wed_Apr__9_15:11:49_2003-1 Content-Type: text/plain; charset=US-ASCII At Wed, 9 Apr 2003 13:43:12 +0200, Gregoire Favre wrote: > > On Wed, Apr 09, 2003 at 01:09:12PM +0200, Takashi Iwai wrote: > > > i can hear ac3 5.1 output over spdif with a terratec xfire 1024 > > without problems. i guess it's not the choice of receiver but the > > card itself. there are differences between the cards even with the > > same cs46xx chip depending on the hardware implementation. > > Well, I can't speak about ALSA, but for DVB card, it only works with > receivers that detect the encapsulated stream (a lots of DVB users have > tested different receivers). > So I ask if it's really not a problem with some receivers here too... > When I plug my 5.1 to my standalone DVD player, I have two choice: > > * SPDIF/RAW > * SPDIF/PCM > > And if I choose SPDIF/PCM it don't work, but SPDIF/RAW works perfectly. hmm, then your receiver needs explicitly the non-audio bit. i guess that my receiver reads the signature bytes for each spdif frame. i tested 44.1kHZ ac3 from diatons, and it works on mine. > > yes it should be a driver bug. > > but note that without the real (problematic) hardware, it's difficult > > to check (especially if the system of developers do really work :) ... > > So I only have the choice to change either the card, or my receier... before giving up: could you try the attached patch (to cvs version)? Takashi --Multipart_Wed_Apr__9_15:11:49_2003-1 Content-Type: application/octet-stream Content-Disposition: attachment; filename="cs46xx-spdif-bits.dif" Content-Transfer-Encoding: 7bit Index: alsa-kernel/pci/cs46xx/cs46xx_lib.c =================================================================== RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/cs46xx/cs46xx_lib.c,v retrieving revision 1.53 diff -u -r1.53 cs46xx_lib.c --- alsa-kernel/pci/cs46xx/cs46xx_lib.c 2 Apr 2003 14:33:48 -0000 1.53 +++ alsa-kernel/pci/cs46xx/cs46xx_lib.c 9 Apr 2003 13:08:02 -0000 @@ -2162,12 +2162,11 @@ int change; down (&chip->spos_mutex); - val = _wrap_all_bits(((u32)ucontrol->value.iec958.status[0] << 24)) | - _wrap_all_bits(((u32)ucontrol->value.iec958.status[1] << 16)) | - _wrap_all_bits( (u32)ucontrol->value.iec958.status[3]) | + val = ((u32)_wrap_all_bits(ucontrol->value.iec958.status[0]) << 24) | + ((u32)_wrap_all_bits(ucontrol->value.iec958.status[1]) << 16) | + (u32)_wrap_all_bits(ucontrol->value.iec958.status[3]) | /* left and right validity bit */ (1 << 13) | (1 << 12); - change = ins->spdif_csuv_stream != val; ins->spdif_csuv_stream = val; --Multipart_Wed_Apr__9_15:11:49_2003-1-- ------------------------------------------------------- This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger for complex code. Debugging C/C++ programs can leave you feeling lost and disoriented. TotalView can help you find your way. Available on major UNIX and Linux platforms. Try it free. www.etnus.com