From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: alsa on non-linux Date: Thu, 16 Jan 2014 14:46:52 +0100 Message-ID: References: <20140110153700.GC1173@quark.internal.precedence.co.uk> <20140114101709.GB160@quark.internal.precedence.co.uk> <52D5440A.6080508@ladisch.de> <20140116132717.GB10286@quark.internal.precedence.co.uk> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 9F61F2616F3 for ; Thu, 16 Jan 2014 14:46:52 +0100 (CET) In-Reply-To: <20140116132717.GB10286@quark.internal.precedence.co.uk> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Patrick Welche Cc: alsa-devel@alsa-project.org, Clemens Ladisch List-Id: alsa-devel@alsa-project.org At Thu, 16 Jan 2014 13:27:17 +0000, Patrick Welche wrote: > > On Tue, Jan 14, 2014 at 03:04:58PM +0100, Clemens Ladisch wrote: > > Patrick Welche wrote: > > > I started out, writing the attached patch in November, but then it looked > > > as though the boundaries of application library interface and linux sound > > > chip driver had become so blurred that I thought that a decision had been > > > taken to bin all OSes bar linux, hence the question. Can you give me a > > > hint on how you think it is supposed to work? > > > > Only the "hw" plugins access the Linux kernel drivers. Anything else > > should be portable (with the exception of plugins like "dmix" that > > require a "hw" plugin as their slave). > > > > For most device types (hwdep/seq/rawmidi/timer), the hw plugin is the > > only implementation, so a portable alsa-lib has only control and pcm > > devices at the moment. > > So, rephrasing for the novice that I am, e.g., include/local.h contains > > #include > ... > #if __BYTE_ORDER == __LITTLE_ENDIAN > ... > #include > #include > > which are portability headaches. local.h is included by > > src/alisp/alisp.c:#include "local.h" > src/conf.c:#include "local.h" > src/confmisc.c:#include "local.h" > src/control/control_local.h:#include "local.h" > src/control/namehint.c:#include "local.h" > src/control/setup.c:#include "local.h" > src/dlmisc.c:#include "local.h" > src/error.c:#include "local.h" > src/hwdep/hwdep_local.h:#include "local.h" > src/input.c:#include "local.h" > src/mixer/mixer_local.h:#include "local.h" > src/names.c:#include "local.h" > src/output.c:#include "local.h" > src/pcm/pcm_local.h:#include "local.h" > src/rawmidi/rawmidi_local.h:#include "local.h" > src/seq/seq_event.c:#include "local.h" > src/seq/seq_local.h:#include "local.h" > src/seq/seq_midi_event.c:#include "local.h" > src/seq/seq_old.c:#include "local.h" > src/socket.c:#include "local.h" > src/timer/timer_local.h:#include "local.h" > src/ucm/ucm_local.h:#include "local.h" > > That is fine except for files under directories src/control and src/pcm > which ought to be portable? Or is it stronger, and everything should be > portable except files under directory src/hwdep? Why excluding hwdep...? And, no, the codes have been written to be portable, but the primary goal is a thin layer for Linux kernel ABI, thus its support is the highest priority. The linux/*.h file inclusions are basically for allowing to include sound/asound.h as is. It's a part of the Linux kernel code, and I don't think we'd add any extra ifdefs there just for non-Linux. IOW, you'd need to prepare some compatible defines before including sound/asound.h if you need to compile for non-Linux systems. Takashi