linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Tony Vroon <chainsaw@gentoo.org>
Cc: linuxppc-dev list <linuxppc-dev@ozlabs.org>,
	Benjamin Berg <benjamin@sipsolutions.net>,
	debian-powerpc <debian-powerpc@lists.debian.org>
Subject: Re: snd-aoa status update / automatic driver loading
Date: Fri, 19 May 2006 12:22:07 +0200	[thread overview]
Message-ID: <1148034127.15507.178.camel@johannes> (raw)
In-Reply-To: <446B721D.8020203@gentoo.org>

[-- Attachment #1: Type: text/plain, Size: 4514 bytes --]

On Wed, 2006-05-17 at 19:57 +0100, Tony Vroon wrote:

> When writing documentation, you might want to add that the ALSA-plugin
> in XMMS & Audacious requires a period time of 100ms instead of the
> default of 50ms, as otherwise the sou*click*nd is n*click*ot ver*click*y
> good.
> (A look at the current code of that plugin, to see how the volume
> control code can be fixed would be highly appreciated)

How's that related to snd-aoa? You can currently buffer up to 131072
bytes which at 96KHz and 32 bits is ~171ms. At the regular 44100Hz/16bit
it is ~743ms. But you can easily increase that in i2sbus-pcm.c line
126ff:
        /* these are somewhat arbitrary */
        hw->buffer_bytes_max = 131072;
        hw->period_bytes_min = 256;
        hw->period_bytes_max = 16384;
The thing is just that this memory area is essentially mlock()ed so if I
did indeed allow 16k per period and 32 periods the stream would mlock
512K. What would others say is appropriate?

Ah then again I can see how this might be related to snd-aoa -- we only
update the pcm position on each period so maybe we should increase the
minimum number of periods. Can you try that? Go into i2sbus-pcm.c line
130 and change
        hw->periods_min = 3;
to maybe 6. Or just try binary search for  smallest value that makes it
work (if it ever does, but I think it should, if this is indeed the
issue). Indeed, at 50ms buffer you have just 8820 bytes which can even
be divided by 3 so that probably means that xmms used 3 periods. Maybe
that's a bit tight. Do you see the same issue with snd-powermac? (it
uses the same period setup)

> Not seen this, although I must say it does not resume from sleep as
> gracefully as I have seen you describe it.

What happens? I just fixed tas resume from sleep (by completely
re-initialising the codec) and something similar should be done for the
onyx probably (or do I do that already?) for suspend to disk, but other
than that... Oh I just realised that it'll lose some sound due to
restarting the dma command ring at the beginning. Hmm. I suppose I can
change that easily, will have to do some testing.

Benjamin (Berg), can we do that even with the lost interrupt issue?

Maybe both of these issues can be fixed by using the frame count
register instead to count how many samples were played? Below is a small
patch to print out a lot of frame count numbers, Benjamin, I'd
appreciate if you could look how this interacted with the lost
interrupts.

Note that for this to work we'd of course have to sample the frame count
register right before starting the DMA engine, it increases even while
we're not playing because we don't stop the clocks. We probably should
do that too for powersaving. Humm. Lots to do :) Oh and this probably
means that yes, it works fine even when we do lose interrupts. 

Alternatively we could use the register just to detect if we lost
interrupts, i.e. calculate how many frames we have per period and then
see if the frame count increased approximately by that much (I've seen
+- a few frames probably due to timing, with higher samplerates we'll
probably see a bit more error) and if it increased by much more we could
estimate how many interrupts we lost. What do you think?

johannes

--- snd-aoa.orig/soundbus/i2sbus/i2sbus-pcm.c	2006-05-19 12:10:16.919474526 +0200
+++ snd-aoa/soundbus/i2sbus/i2sbus-pcm.c	2006-05-19 12:11:22.119474526 +0200
@@ -488,12 +488,17 @@ static snd_pcm_uframes_t i2sbus_pcm_poin
 static inline void handle_interrupt(struct i2sbus_dev *i2sdev, int in)
 {
 	struct pcm_info *pi;
+	u32 fc;
 
 	get_pcm_info(i2sdev, in, &pi, NULL);
 	if (!pi->substream) {
 		printk(KERN_INFO "i2sbus: got %s irq while not active!\n", in?"rx":"tx");
 		return;
 	}
+	fc = in_le32(&i2sdev->intfregs->frame_count);
+	printk(KERN_DEBUG "i2sbus: frame count is %d\n", fc);
+	printk(KERN_DEBUG "i2sbus: delta fc = %d\n", fc - i2sdev->fc);
+	i2sdev->fc = fc;
 	pi->current_period = (pi->current_period+1) % (pi->periods);
 	snd_pcm_period_elapsed(pi->substream);
 }
--- snd-aoa.orig/soundbus/i2sbus/i2sbus.h	2006-05-19 12:10:16.919474526 +0200
+++ snd-aoa/soundbus/i2sbus/i2sbus.h	2006-05-19 12:11:22.119474526 +0200
@@ -50,6 +50,7 @@ struct i2sbus_dev {
 	struct macio_dev *macio;
 	struct i2sbus_control *control;
 	volatile struct i2s_interface_regs __iomem *intfregs;
+	u32 fc;
 
 	int resource_allocated; /* bitmask of resources */
 	struct resource resources[3];


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 793 bytes --]

  reply	other threads:[~2006-05-19 12:47 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-17 10:09 snd-aoa status update / automatic driver loading Johannes Berg
2006-05-17 18:57 ` Tony Vroon
2006-05-19 10:22   ` Johannes Berg [this message]
2006-05-20 23:56     ` Benjamin Herrenschmidt
2006-05-22  6:42       ` Johannes Berg
2006-05-23 22:15         ` Benjamin Herrenschmidt
2006-05-24  9:42           ` Johannes Berg
2006-05-25  8:00             ` Benjamin Herrenschmidt
2006-05-25  9:42               ` Johannes Berg
2006-05-26  1:30                 ` Benjamin Herrenschmidt
2006-05-17 19:53 ` Andreas Schwab
2006-05-18 10:14   ` Johannes Berg
2006-05-17 21:54 ` Wolfgang Pfeiffer
2006-05-17 22:19   ` Wolfgang Pfeiffer
2006-05-18 10:13     ` Johannes Berg
2006-05-18 18:17       ` Wolfgang Pfeiffer
2006-05-18 22:06         ` Andreas Schwab
2006-05-19 12:50         ` Johannes Berg
2006-05-19 14:40           ` Wolfgang Pfeiffer
2006-05-19 14:40             ` Johannes Berg
2006-05-17 22:30   ` Dean Hamstead
2006-05-18  0:28     ` Wolfgang Pfeiffer
2006-05-18  0:39       ` Dean Hamstead
2006-05-18  1:01   ` Wolfgang Pfeiffer
2006-05-18  1:08   ` Benjamin Herrenschmidt
2006-05-18  7:25 ` Eddy Petrişor
2006-05-18 10:23   ` Johannes Berg
2006-05-19 13:20     ` Paul Collins
2006-05-19 13:46       ` Johannes Berg
2006-05-19 14:40         ` Paul Collins
2006-05-19 14:49           ` Johannes Berg
2006-05-19 15:13             ` Paul Collins
2006-05-19 14:33       ` Andreas Schwab
2006-05-19 14:37         ` Johannes Berg
2006-05-23 15:41       ` Sjoerd Simons
2006-05-25  7:21         ` Eddy Petrişor
2006-05-25  7:21           ` Eddy Petrişor
2006-05-25  9:43           ` Johannes Berg
2006-05-25 17:44     ` Eddy Petrişor
2006-05-25 18:47       ` Johannes Berg
2006-05-18  8:56 ` Rene Rebe
2006-05-18 10:08   ` Johannes Berg
     [not found] ` <200605180002.01669.borge@arivene.net>
     [not found]   ` <20060518004141.GC1552@kunpuu.plessy.org>
2006-05-20 14:57     ` Benjamin Berg
2006-05-20 23:59       ` Benjamin Herrenschmidt
2006-05-23  3:11 ` Hollis Blanchard
2006-05-23 12:27   ` Johannes Berg
2006-05-23 14:46     ` Hollis Blanchard
2006-05-23 15:25       ` Hollis Blanchard
2006-05-24  9:41       ` Johannes Berg

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=1148034127.15507.178.camel@johannes \
    --to=johannes@sipsolutions.net \
    --cc=benjamin@sipsolutions.net \
    --cc=chainsaw@gentoo.org \
    --cc=debian-powerpc@lists.debian.org \
    --cc=linuxppc-dev@ozlabs.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;
as well as URLs for NNTP newsgroup(s).