Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: asbjs@stud.ntnu.no (Asbjørn Sæbø)
To: alsa-devel@alsa-project.org
Subject: Distorted sound writing audio to Delta 44 sound card
Date: Tue, 8 Nov 2005 15:19:27 +0100	[thread overview]
Message-ID: <20051108141927.GA2923@stud.ntnu.no> (raw)

I am developing an application for transmission of audio over IP.
(See http://www.q2s.ntnu.no/~asbjs/ldas/ldas.html )

I did have two-way transmission working between two computers equipped
with SoundBlaster Live cards.  But when I swithced one of the sound
cards for a M-Audio Delta 44, the audio transmitted to this computer
became very distorted.  (I describe the situtation in more detail
below.)  Any advice regarding what may be the cause of this, and how it
can be fixed, would be very welcome.  I am especially interested in 
comments on the code lines included at the bottom.


Description
-----------
The audio transmitted from the Delta 44-equipped computer to the SBLive
equipped one comes out fine, as before.  But the audio transmitted the
other way, from the SBLive computer to the Delta 44 computer comes out
very distorted.  The distorted signal is clearly correlated to the
original signal.  The distortion is not noise, neither is it the result 
of clipping or overdriving.  (It sounds kind of like a model airplane
engine modulated in some way by the original signal.)

Furthermore, instead of having signal on two channels as expected (the
transmitted signal is stereo), the Delta 44 has signals on all eight
"PCM Out"  channels shown by the mixer (envy24control).  When
transmitting music, all of these channels sound quite alike, with the
same distorted signal.  When transmitting a click track, the clicks come
and go (a few clicks are heard, then there is silence for a few clicks)
for many of the channels.


Theories and questions
----------------------
I have been adviced that the Delta 44 is a 24 bit device, and that 
opening the "plughw:0,0" device (instead of the "default" device) might 
give better results.  But this does not seem to be the case.  Actually 
it seems that the plughw layer is used anyhow, snd_pcm_dump() gives the 
same output in both cases, showing a PLAYBACK device with 
MMAP_INTERLEAVED access, S16_LE format and two channels (equal to the 
SBLive setup) and the actual Delta 44 card as a "Slave".

I am not very familiar with this plughw layer.  But can I assume that
the resulting device can be accessed and used like a "real" card with 
the same properties reported by snd_pcm_dump()?  Or are there any 
subtleties that one should care for when transferring data to the card 
(or otherwise)?

I suspect that the problem may be connected to the conversion from a
series of bytes transmitted on the network to audio frames that I write
to the sound card.  If something goes astray in this mapping, it may
very well explain the observed behaviour.  
Details of the conversion follows below.  This worked before the sound
card was changed.  Are there any reasons that is should not work now
that the SBLive has been replaced with the Delta 44?

-------------------------------------------

typedef int databuffer_t[BUFFERBYTES / 4];   
    /* A frame is 4 bytes (2 channels, 16 bits), an int is 4 bytes */
const snd_pcm_channel_area_t *dst_area; 
databuffer_t *dst_address;  


retval = snd_pcm_mmap_begin(receiver->soundcardh, &dst_area, 
                                &offset, &frames);

    /*  dst_area->address is "base address of channel samples"
     *  dst_area->first is "offset to first sample in bits".  
     *  (Seems to be zero here.  Does this come in addition to "offset"?  
     *  If so, add dst_area->first/8 to dst_address.)
     *
     *  offset is "Returned mmap area offset in area steps (== frames)".
     *  The documentation does not say so specifically, but it seems 
     *  that the pcm_area that we
     *  get access to trough the snd_pcm_mmap_begin() call should be 
     *  used from the offset off.  
     *  (The number of bytes per frame is given by SND_FRAME_BYTES.)
     */   
dst_address = (databuffer_t *) ((char *)dst_area->addr + 
                                      offset*SND_FRAME_BYTES);
retval = queuecopydata(&queue, dst_address, &pool);

nwritten = snd_pcm_mmap_commit(receiver->soundcardh, offset, frames);

--------------------------------------------------

Where queuecopydata() mainly copies data from the queue to the area 
starting at dst_address, an int at a time.  (An int is used for a 
frame of data, since in this case, both are four bytes.  Ugly, I 
know.)




Asbjørn Sæbø



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php

                 reply	other threads:[~2005-11-08 14:19 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051108141927.GA2923@stud.ntnu.no \
    --to=asbjs@stud.ntnu.no \
    --cc=alsa-devel@alsa-project.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox