Hozzászólások
-
Bejegyzés
-
Megvan a megoldás, a bttv modult meg kell kínálni még egy paraméterrel:
Code:modprobe bttv card=42 tuner=28 radio=1 i2c_udelay=16i2c_udelay= Allow reduce I2C speed. Default is 5 usecs (meaning 66,67 Kbps). The default is the maximum supported speed by kernel bitbang algorithm. You may use lower numbers, if I2C messages are lost (16 is known to work on all supported cards).
Így már tökéletes a kép és a hang is, egyedül a kernelbe épített ir támogatás nem működik. A lirc csomaggal megy az is.
Megvan a megoldás, a bttv modult meg kell kínálni még egy paraméterrel:
Code:modprobe bttv card=42 tuner=28 radio=1 i2c_udelay=16i2c_udelay= Allow reduce I2C speed. Default is 5 usecs (meaning 66,67 Kbps). The default is the maximum supported speed by kernel bitbang algorithm. You may use lower numbers, if I2C messages are lost (16 is known to work on all supported cards).
Így már tökéletes a kép és a hang is, egyedül a kernelbe épített ir támogatás nem működik. A lirc csomaggal megy az is.
Előhoznám a topikot, a probléma ugyanaz. A scrpit ennyit változott:
Code:#!/bin/shload()
{
modprobe bttv card=42 tuner=28 radio=1
until dmesg | grep „pic16c54 (PV951) found @ 0x96” ; do
rmmod tvaudio
modprobe tvaudio
count=`expr $count + 1`
echo $count
done
}unload()
{
killall lircd
for i in ir-kbd-i2c bttv videodev tveeprom btcx_risc compat_ioctl32 video_buf tuner tvaudio v4l2_common v4l1_compat ir_common
do
rmmod $i 2>/dev/null
done
dmesg -c
}ir()
{
modprobe ir-kbd-i2c
until dmesg | grep „i2c IR (PV951) detected at i2c” ; do
rmmod ir-kbd-i2c
modprobe ir-kbd-i2c
count=`expr $count + 1`
echo $count
done
}demon()
{
lircd -H dev/input -d /dev/input/event2
}count=0
$1gendelider wrote:Hali!
A régi kernelt és környezetét nem szoktad „megtartani”, hogy arról is tudjál bootolni? Mert akkor könnyen visszamérhető. A kísérletek között mindenképpen kikapcsolnám a gépet, nem csak warm start.Megvan a régi kernel és környezete, 2.6.18-gr6 és korábbi kernelekkel működik a dolog cold és warm start esetén is (windows alatt is tökéletesen működik a kártya). Ez felett viszont egyik kernellel sem. Amiket próbáltam: 2.6.20-gentoo-r7 2.6.20-gentoo-r8 2.6.22-gentoo-r5 2.6.22.5 vanilla.
gendelider wrote:Hali!
Egyébként az olvasott ff vagy ffff … értékek gyanúsak, mert azt jelenti, hogy nem sikerült elérni egy – vagy több – HW regisztert. (A levegőben lógnak, és akkor „fel vannak húzva” 1-re) Volt már ilyen az életemben, akkor HW, illetve a HW programozása volt a hunyó. Lehet az is, hogy az alaplapi chipset (valamelyik bridge) vezérlésében nem stimmel valami.Az „öregedő” HW-ben kevésbé hiszek, inkább nem korrekt HW / driver megoldásokban, egy „nagyon a szélére” (a felfutó/lefutó él mellé közvetlenül) programozott bus i/o -ban. A kontakthibák sem jellemzőek már annyira manapság.
Ha erről van szó én mint egyszerű felhasználó mit tudok vele kezdeni?
Előhoznám a topikot, a probléma ugyanaz. A scrpit ennyit változott:
Code:#!/bin/shload()
{
modprobe bttv card=42 tuner=28 radio=1
until dmesg | grep „pic16c54 (PV951) found @ 0x96” ; do
rmmod tvaudio
modprobe tvaudio
count=`expr $count + 1`
echo $count
done
}unload()
{
killall lircd
for i in ir-kbd-i2c bttv videodev tveeprom btcx_risc compat_ioctl32 video_buf tuner tvaudio v4l2_common v4l1_compat ir_common
do
rmmod $i 2>/dev/null
done
dmesg -c
}ir()
{
modprobe ir-kbd-i2c
until dmesg | grep „i2c IR (PV951) detected at i2c” ; do
rmmod ir-kbd-i2c
modprobe ir-kbd-i2c
count=`expr $count + 1`
echo $count
done
}demon()
{
lircd -H dev/input -d /dev/input/event2
}count=0
$1gendelider wrote:Hali!
A régi kernelt és környezetét nem szoktad „megtartani”, hogy arról is tudjál bootolni? Mert akkor könnyen visszamérhető. A kísérletek között mindenképpen kikapcsolnám a gépet, nem csak warm start.Megvan a régi kernel és környezete, 2.6.18-gr6 és korábbi kernelekkel működik a dolog cold és warm start esetén is (windows alatt is tökéletesen működik a kártya). Ez felett viszont egyik kernellel sem. Amiket próbáltam: 2.6.20-gentoo-r7 2.6.20-gentoo-r8 2.6.22-gentoo-r5 2.6.22.5 vanilla.
gendelider wrote:Hali!
Egyébként az olvasott ff vagy ffff … értékek gyanúsak, mert azt jelenti, hogy nem sikerült elérni egy – vagy több – HW regisztert. (A levegőben lógnak, és akkor „fel vannak húzva” 1-re) Volt már ilyen az életemben, akkor HW, illetve a HW programozása volt a hunyó. Lehet az is, hogy az alaplapi chipset (valamelyik bridge) vezérlésében nem stimmel valami.Az „öregedő” HW-ben kevésbé hiszek, inkább nem korrekt HW / driver megoldásokban, egy „nagyon a szélére” (a felfutó/lefutó él mellé közvetlenül) programozott bus i/o -ban. A kontakthibák sem jellemzőek már annyira manapság.
Ha erről van szó én mint egyszerű felhasználó mit tudok vele kezdeni?
Nekem ez jobban bejött.
Nekem ez jobban bejött.
Még egy tippem lenne, nekem is volt ilyen problémám igaz gentoo alatt, hogy a mencoder nem rögzített hangot. Nekem az oldotta meg hogy oss támogatással újraforgattam.
Még egy tippem lenne, nekem is volt ilyen problémám igaz gentoo alatt, hogy a mencoder nem rögzített hangot. Nekem az oldotta meg hogy oss támogatással újraforgattam.
Soltan wrote:Nem most már nem, és szegmens hiba sincs. Elindul szépen a felvétel de hang nincs hozzá.
Szerk.: Az alsamixerben a line-in maximunon van.Code:alsamixer -V captureA line van megjelölve forrásnak, valamint a capture csuszkánál a felvételi szint be van állítva?
legutóbbi hsz