[linux-sunxi] Playback and capture audio at the same time in Cubieboard4(CC-A80)

[孙鹏]

Hi

I have got the problem: : http://www.cubieforums.com/index.php/topic,4145.0.html

i use cb4(CC-A80)  linao dekstop,   after install pluseadio, setting 
pulseaudio's   Configuration--》 snddaudio  profile : Analog Stereo Duplex.

capture audio use the alsa-lib command:
#arecord -vv -t wav -f S16_LE -c 2 -d 10 -r 24000 ./test.wav

at the same time i play audio using speaker test  or chromium
#speaker-test -t wav  

but the play audio is normal, but capture audio is no normal, it is  no 
continuous.  
i think it is the drivers problems. Can anyone has a good idea?





--
 Sincerely,Sam ( 孙鹏 )
QQ:810119017
Email: s...@cubietech.com
深圳方糖电子有限公司

Shenzhen CubieTech Limited

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Thomas Kaiser]

Hi,

Ondřej Jirman wrote:
>
> We have boards that have 1.1/1.3V switching, only 1.3V, fine tuned 
> voltage regulation and every such board will need it's own set of 
> operating points. 
>

Yes, and Allwinner's current BSP kernel code might encourage board makers 
to implement a forth variant: switching between 4 different voltages 
through GPIOs.

Currently we have 4 boards that rely on the simple '2 voltage regulation' 
all using 1.1V/1.3V: Orange Pi One and Lite and NanoPi M1 and NEO. Then 
there are 2 devices with (legacy) Linux support existing that use no 
voltage regulation at all: Banana Pi M2+ (according to schematic using 1.2V 
but in reality it's 1.3V VDD_CPUX) and Beelink X2. And according to Tsvetan 
if/when Olimex will release their 2 H3 boards we have two more with fixed 
but yet unknown VDD_CPUX voltage (since olimex fears overheating maybe they 
use 1.1V or 1.2V limiting max cpufreq to 816 or 1008 MHz). And all the 
bigger H3 based Orange Pi use the SY8106A voltage regulator being able to 
adjust VDD_CPUX in steps of 20mV allowing VDD_CPUX to exceed 1200 MHz (a 
reasonable value seems to be 1296 MHz since above throttling will be an 
issue without active cooling)

Things get even worse since Xunlong uses copper layers inside the PCB to 
spread the heat away from H3 so Orange Pi One/Lite do not overheat that 
much like eg. NanoPi M1 (and maybe NEO -- can tell next week when I get dev 
samples to play with). So while eg. Orange Pi One and NanoPi M1 switch 
between the same voltages in the same way we (Armbian) found that we have 
to allow M1 to downclock to even 240 MHz since when testing with legacy 
kernel really heavy workloads led to throttling that low (even CPU cores 
were killed at this low clockspeed -- same applies to BPi M2+ and Beelink 
X2)

So i would second Ondřej's suggestions since when we're talking about H3 
devices we're not talking about tablet SoCs with accompanied PMU but 3 
classes of devices behaving totally different in regard to cpufreq limits 
and dvfs OPPs (and maybe someone is already developing a new H3 device 
adding a forth variant switching between 4 different VDD_CPUX voltages)

Thomas

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Jean-Francois Moine]

On Fri, 15 Jul 2016 12:38:54 +0200
Ondřej Jirman  wrote:

> > If so, then yes, trying to switch to the 24MHz oscillator before
> > applying the factors, and then switching back when the PLL is stable
> > would be a nice solution.
> > 
> > I just checked, and all the SoCs we've had so far have that
> > possibility, so if it works, for now, I'd like to stick to that.
> 
> It would need to be tested. U-boot does the change only once, while the
> kernel would be doing it all the time and between various frequencies
> and PLL settings. So the issues may show up with this solution too.

I don't think this is a good idea: the CPU clock may be changed at any
time with the CPUFreq governor. I don't see the system moving from
1008MHz to 24MHz and then to 1200MHz when some computation is needed!

BTW, Ondřej, in my BPi M2+, I tried to change the CPU clock with your
code at kernel start time from 792MHz to 1008MHz, but the hardware
(arisc?) set an other value, and the system speed was lower than before
(the PLL-CPUx register is 0x90031521 on boot, I want to set it to
1410 and I read 0x91031f33 - sorry, I did not have a look at the
CPU SD pattern). Do you know why?

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.